Announcing Reality 4 {Commercial}

11516171921

Comments

  • kyoto kidkyoto kid Posts: 41,042
    edited December 1969

    ...OK Downloaded the update but haven't installed yet. Do I have to go and delete everything from the previous version off my system all over again before installing?

  • TJohnTJohn Posts: 11,099
    edited December 1969

    Kyoto Kid said:
    ...OK Downloaded the update but haven't installed yet. Do I have to go and delete everything from the previous version off my system all over again before installing?

    From the Update email:
    Capture.JPG
    912 x 255 - 30K
  • kyoto kidkyoto kid Posts: 41,042
    edited December 1969

    ..OK thanks.

    Thought I read in another thread that I would need to remove all traces of the older version since there is no uninstaller..

  • Vertigo789Vertigo789 Posts: 74
    edited January 2015

    Cheers for the answers, I suppose we just have to hope that they improve the ability to edit multiple items in a future update.

    I tested out rendering with the pure GPU setting, and it didn't render any textures, just the models. Is this due to VRAM limitations?

    Also, Bi-directional rendering seems to be much slower, and always results in a large number of white specks and fireflies that never go away, but just increase as the render goes on. I use Mono-directional instead, which works perfectly for me, but is there an advantage to Bi-directional, and if so, what's causing the visual issues that don't appear when using the Mono-directional method?

    Could anyone answer this, please?

    Also, sometimes when I leave a render going and come back to check after a few hours, the PC will have restarted, saying there was an unexpected shutdown, the image file will be corrupt and when I resume the render, there'll be a dark patch over the image. So presumably this happens when the render is auto-saving the FLM file. Is this a result of high memory usage, or a side-effect of leaving the computer idle? I'm using Luxrender 1.3.1 for what it's worth.

    Post edited by Vertigo789 on
  • DustRiderDustRider Posts: 2,743
    edited January 2015

    Cheers for the answers, I suppose we just have to hope that they improve the ability to edit multiple items in a future update.

    I tested out rendering with the pure GPU setting, and it didn't render any textures, just the models. Is this due to VRAM limitations?

    Also, Bi-directional rendering seems to be much slower, and always results in a large number of white specks and fireflies that never go away, but just increase as the render goes on. I use Mono-directional instead, which works perfectly for me, but is there an advantage to Bi-directional, and if so, what's causing the visual issues that don't appear when using the Mono-directional method?

    Could anyone answer this, please?

    Also, sometimes when I leave a render going and come back to check after a few hours, the PC will have restarted, saying there was an unexpected shutdown, the image file will be corrupt and when I resume the render, there'll be a dark patch over the image. So presumably this happens when the render is auto-saving the FLM file. Is this a result of high memory usage, or a side-effect of leaving the computer idle? I'm using Luxrender 1.3.1 for what it's worth.

    The Bi-directional vs Mono-directional (also know as uni-directional) question doesn't have a real simple answer, but in general with Mono-directional the light rays are "shot" from your light source(s) in all directions. and the ray paths are traced until they hit something, where the ray is bounced (reflected/refracted, etc.) and continues to be traced until it hits another object, where it is bounced again, and repeat until the maximum number of bounces is reahced, the maximum path distance is reached, or the camera is hit. Bi-directional traces ray paths from both the light source(s) and the camera, which in most situations will improve the speed of image resolution. The speed in s/s of Bi-directional will usually be "slower" than what is reported for Mono-directional, but the time it takes to resolve the image will typically be faster.

    The following is from a Wikipedia atrticle on Path Tracing (http://en.wikipedia.org/wiki/Path_tracing)
    Sampling the integral for a point can be done solely by using any one of the following two distinct approaches:

    Shooting rays from the light sources and creating paths in the scene. The path is cut off at a random number of bouncing steps and the resulting light is sent through the projected pixel on the output image. During rendering, billions of paths are created, and the output image is the mean of every pixel that received some contribution.
    Gathering rays from a point on a surface. A ray is projected from the surface to the scene in a bouncing path that terminates when a light source is intersected. The light is then sent backwards through the path and to the output pixel. The creation of a single path is called a "sample". For a single point on a surface, approximately 800 samples (up to as many as 3 thousand samples) are taken. The final output of the pixel is the arithmetic mean of all those samples, not the sum.
    Bidirectional Path Tracing combines both Shooting and Gathering in the same algorithm to obtain faster convergence of the integral. A shooting path and a gathering path are traced independently, and then the head of the shooting path is connected to the tail of the gathering path. The light is then attenuated at every bounce and back out into the pixel. This technique at first seems paradoxically slower, since for every gathering sample we additionally trace a whole shooting path. In practice however, the extra speed of convergence far outweighs any performance loss from the extra ray casts on the shooting side.

    Your lack of textures in the GPU only render could be due to several different issues including; not enough RAM (as you mentioned), use of materials that aren't supported by SLG (the GPU renderer), or failure to use the "collect textures" option. In general, pure GPU rendering with Lux 1.3 is still pretty much "Black Box", which means if you aren't into learning a lot about Lux and SLG from the forums and technical documentation (and used to crashing your video drivers), it really isn't recommended for the casual user.

    To answer the question about why Bi-directional is causing more noise than Mono-directional its hard to say. We would need more information about your scene including lights used and light settings, your tone mapping settings in Lux, are you using CPU only or hybrid rendering (I'm guessing your are using hybrid, it often is more difficult to get images to clear up with it) and a image of the scene your trying to render.

    Similarly, to get a good idea what might be causing your renders to crash we would need more information about the type of computer, what your system specs are, and the info requested above. I'm guessing that it is probably either your computer is overheating and shutting down, or you are running out of RAM and it is shutting down. Getting your system info and the render settings info will be a huge aid in diagnosing what might be going on.

    Post edited by DustRider on
  • Vertigo789Vertigo789 Posts: 74
    edited January 2015

    Thanks for the help. I don't have a scene to render right now, so I'll put one together when I have the chance so I can test out the two methods again. I do use the hybrid method, yeah, it seems to perform better than with no acceleration (e.g. a scene that increases by 0.02 S/P per second without any acceleration will increase by 0.08 with hybrid mode enabled).

    My specs are Windows 7 64 bit, i7 4770K OC'd to 4.2 GHz, GTX 770 2GB and 16GB RAM. The crashes, when they happen, seem to always occur during an autosave of the FLM file in Lux (as the image file is usually corrupt, and there might be a temp file in the directory that is used whenever the program is saving the FLM), so I'm guessing there's some spike in memory or CPU usage when this happens, which probably pushes my PC far enough to shut down and reboot. I generally render in 1920x1080 (though I do test renders in half of that resolution).

    Post edited by Vertigo789 on
  • DustRiderDustRider Posts: 2,743
    edited January 2015

    Thanks for the help. I don't have a scene to render right now, so I'll put one together when I have the chance so I can test out the two methods again. I do use the hybrid method, yeah, it seems to perform better than with no acceleration (e.g. a scene that increases by 0.02 S/P per second without any acceleration will increase by 0.08 with hybrid mode enabled).

    My specs are Windows 7 64 bit, i7 4770K OC'd to 4.2 GHz, GTX 770 2GB and 16GB RAM. The crashes, when they happen, seem to always occur during an autosave of the FLM file in Lux (as the image file is usually corrupt, and there might be a temp file in the directory that is used whenever the program is saving the FLM), so I'm guessing there's some spike in memory or CPU usage when this happens, which probably pushes my PC far enough to shut down and reboot. I generally render in 1920x1080 (though I do test renders in half of that resolution).


    I think the problem for both issues is using hybrid rendering.

    Definitely the issue of bi-directional having more noise than mono-directional is the use of the hybrid renderer, I've never been able to get images to completely clear up using bi-directional and hybrid. It also been my experience that even though the hybrid renderer is quite a bit faster in samples per second, it will typically take a lot longer for the image to clear up. IMHO neither the GPU or the Hybrid renderers are quite ready for prime time. The upcoming release of LuxRender 2 (LuxCore) will change this situation. Until Lux 2, or maybe Lux 1.5 come out, I think your definitely better off using pure CPU rendering, and even though it seems slower, you'll get a refined image faster. The two images below clearly illustrate this. I let both run for 2 min., the CPU only render is the better of the two (top image), even though it's only running at 44 Ks/s compared to the 122 Ks/s of the hybrid renderer.

    I'm also 99% sure your crashing issues are due to using the hybrid rendering mode (though it is possibly a overheating problem). Due to the way it has to handle memory, it continually eats up more memory the longer it runs, you will definitely run out of memory if left running over night. I just tested this with Lux1.4, and 1.4 eats memory as well. You can easily test this yourself. Start a hybrid render, open task manager, and take note of the total system memory usage. come back a half hour later, and note how much less free system memory you have.

    For monitoring your system (CPU, GPU, memory, etc), Open Hardware monitor is a great little free application - http://openhardwaremonitor.org/

    Hope this helps!!

    Hybrid.JPG
    1040 x 948 - 233K
    CPU.JPG
    1059 x 949 - 152K
    Post edited by DustRider on
  • Vertigo789Vertigo789 Posts: 74
    edited January 2015

    I'm not sure if the crashing is due to overheating, considering I was rendering today for several hours with the CPU temperature hovering at around 75 degrees celsius. I suppose it could be a result of hybrid rendering, so I'll do some test renders later to compare the difference on my machine. What settings should I use for the scene configuration (specifically camera passes, light passes, light strategy, FFS removal and noise aware)?

    Regarding memory usage, yeah, I've noticed that it tends to steadily climb as time goes on, though most of the time it falls short of seriously getting my memory usage to 100% (though I recall this happening once, and I was getting low memory warnings. Then when I resumed the render the next day, the memory usage was far less severe).

    So regarding Luxrender 2, is there an ETA on the release for that? Or is it pretty far off?


    EDIT: Ok, did some tests. Loaded up Genesis 2 Male, with a single mesh light in the default position, and a primitive plane in the background. Here are the results after rendering each for a minute.

    First shot is hybrid rendering with Bidirectional enabled. Third highest S/P value out of all three.

    The second shot is no acceleration with Bidirectional. Lowest S/P value, but far cleaner than the first shot.

    The third shot is no accleration with Monodirectional. Slightly more S/P than hybrid with Bidirectional. Seems about as clean as shot 2, but with less white specks and red fireflies. CPU efficiency was at around 113% compared to around 223% for the other methods.

    The fourth shot is hybrid acceleration with Monodirectional. Most S/P out of all the shots, probably also the cleanest with far less white specks and red fireflies, but also with about 2GB memory usage instead of 1GB.

    Scene configuration for Bidirectional was 16 camera passes, 16 light passes, auto light strategy, noise aware unchecked, and FFs removal set to 3. Monodirectional was 16 max path length, auto light strategy, no noise aware and 3 FFs removal. Film ISO was also set to 125, initially to compensate for the darkness of the first hybrid shot.

    Hybrid_Monodirectional.jpg
    960 x 540 - 379K
    Normal_Monodirectional.jpg
    960 x 540 - 388K
    Normal_Bidirectional.jpg
    960 x 540 - 379K
    Hybrid_Bidirectional.jpg
    960 x 540 - 494K
    Post edited by Vertigo789 on
  • DustRiderDustRider Posts: 2,743
    edited December 1969

    Thanks for posting, these are very interesting results. They made me a bit more curious about GPU rendering in the newer version of Lux. One important note, I'm using Lux 1.4, which is still in beta and is not supported with Reality 4 (just a word of caution, if you use 1.4 and have problems Paolo can't support you, the betas change too rapidly for a single developer like Paolo to effectively support).

    I tried the scene I used above with Hybrid rendering and Mono-directional. I was pleasantly surprised that the image started to clear up rather rapidly, and my Samples/Sec were over 3x what I get with pure CPU rendering. It took more samples per pixels to get results similar in quality to what I got with CPU only and Bi-directional (~4,400 s/px compared to ~3,000 s/px, but the total time to achieve the same quality was about 1/3. Plus, there were no firefly's od red pixels in the Hybrid/mono-directional render like I got in the CPU/Bi-directional render.

    The down side was memory usage. Unlike in Lux 1.2 (it was the last version I did any extensive hybrid testing on), the increase in memory usage did stop after about 2.5-3 hours, where 1.2 would just keep consuming RAM until I ran out (I only had 12Gb then, now I have 24Gb). Lux ended up consuming a total of about 7.5Gb for this simple scene (rendered at 1,000 x 1,200). Memory consumption could be reduced a bit by removing 1 or 2 lights (it has a 3 light setup), but it is definitely memory hungry.

    I'm running the same scene/setup in 1.3 right now to see how it performs, and to see if the memory usage caps like in 1.4. I'll post back after I get some definitive results.

    So, depending on what kind of scene you were rendering, and how many lights were in it (more lights and larger render sizes will quickly increase RAM usage), Lux could have easily maxed out your system RAM, and started swapping to disk (or possibly even maxed out all logical RAM), causing an unrecoverable system error. Another option would be that the increased heat generated by both the GPU and CPU working very hard for an extended period may have caused the system to overheat.

    Regarding Lux 2.0 (also know as FrankenLux) and LuxCore (the LuxRender 2 API), I'm not sure when it will be out, I saw Jan. 2015 as a possible target date in a forum somewhere, but I doubt that we will see it before the end of the month, but it will probably be out before the end of the year. SphericLabs has provided a Beta/Preview of a new product he is developing with LuxCore for Carrara (LuxusCore) over in the Carrara forum, so it shouldn't be too much longer. So far with pure CPU (not GPU) rendering with LuxusCore I've been getting about 0.9-1.1 .Ms/s (Million samples per second) on simple scenes with one clothed G2F figure (compared to about 75-200Ks/s with Lux 1.4).

  • kyoto kidkyoto kid Posts: 41,042
    edited December 1969

    ...only have 12GB here. That's not good if Lux consumes so much memory particularly as I tend to do fairly large involved scenes. A couple years ago when I built this system it was a beast, now it seems more like a kitten. I know I still can upgrade to 24 GB (the most the MB supports) but there is an added cost in having to also upgrade to Win7 Pro to use it all which also means wiping the Boot/Application drive and reinstalling everything all over again, including all the MS updates and patches (which are most likely in the 1,000s by now) as well as drivers.

  • Vertigo789Vertigo789 Posts: 74
    edited January 2015

    Yeah, I've been doing some more testing today, and without fail bidirectional with no acceleration will always result in a large number of white specks and red SSS dots, while hybrid mono tends to clean that up pretty quickly (though I do tend to still get a number of areas on certain characters filled with SSS dots). Setting FFs removal to 10 helped with cleaning up the bidirectional render, but I don't know how heavily it would impact the overall render time. Also I'm using Lux 1.3.1. The new version of Lux can't some soon enough, because hybrid is currently a serious memory hog, but performs a lot better for me than the other methods.

    With regards to the attached pictures, I rendered each for 5 minutes.

    First picture is hybrid monodirectional. Auto light strategy, 0 ffs removal, 16 max path length - 4gb memory usage, 328% eff, 100% gpu, 87.06 s/p.

    Second picture is no acceleration bidirectional. 16 cam and light passes, light strategy set to "all", 0 ffs removal - 1.6gb memory usage, 999% eff, 34.65 s/p.

    Third picture is the same as the second one, but with FFs removal set to 10.

    As you can see, the first picture provides the best image quality, though bidirectional seems to do a better job of lighting up the room. FFs removal does a good job of cleaning up, but again, I'm unsure if it would heavily impact the render time for a full-resolution version.

    4_FFs_Removal.jpg
    1200 x 675 - 286K
    2_No_Acc_Bidirectional.jpg
    1200 x 675 - 283K
    1_Hybrid_Monodirectional.jpg
    1200 x 675 - 439K
    Post edited by Vertigo789 on
  • Robert FreiseRobert Freise Posts: 4,444
    edited December 1969

    Kyoto Kid said:
    ...only have 12GB here. That's not good if Lux consumes so much memory particularly as I tend to do fairly large involved scenes. A couple years ago when I built this system it was a beast, now it seems more like a kitten. I know I still can upgrade to 24 GB (the most the MB supports) but there is an added cost in having to also upgrade to Win7 Pro to use it all which also means wiping the Boot/Application drive and reinstalling everything all over again, including all the MS updates and patches (which are most likely in the 1,000s by now) as well as drivers.

    I upgraded W7 standard or whatever it was called to W7Pro without loss of settings or anything had no problems until as forced by updates to go to win 8.1

  • kyoto kidkyoto kid Posts: 41,042
    edited December 1969

    ...unfortunately MS stopped selling "Anytime Upgrade" keys in late 2013, so now I have to either get the full Win7 Pro OEM and do a clean install, or pay 400$ at Amazon for an upgrade key.

  • DustRiderDustRider Posts: 2,743
    edited December 1969

    With Lux 1.3.2 the memory consumption is about the same, after running 3 hrs and 40 min it was at about 7.5Gb and consuming about 100Mb of RAM approx. every 40 min. (about 1Gb every 6.5 hours). A larger more complex scene, or a scene with more lights, or larger render size, would consume RAM at a faster rate.

    On thing to keep in mind with the Hybrid rendering is that Lux has to essentially double the amount of data for the render. Lux keeps separate image data for each light (or light group), that is why you can adjust the lights without re-starting the render. So when using Hybrid rendering Lux has to store the results as it is rendering for both the CPU and GPU rendering in RAM, then combine them together. It's much more complex and "data" intensive than just using CPU only rendering. It may also have to store separate geometry and materials data for the GPU and CPU portions of the render.

    Using CPU only rendering is definitely going to be much less RAM intensive, but even with CPU rendering you may need to do things like set-up your light intensities properly in Reality and group your lights to reduce the amount of RAM required, especially if you are rendering at very high resolutions (for example 3,000 x 3,000 or greater).

  • cwichuracwichura Posts: 1,042
    edited December 1969

    Keep in mind, hybrid mode has basically been abandoned by the Lux devs. Hybrid BiDir is very broken, and should never be used. If you insist on using Hybrid mode, you MUST use Hybrid Path. Even the Lux devs will tell you this. Hybrid Path (or "mono-directional" in Reality 4 speak) mostly works (there are a few (esoteric) features that are not supported), but is still a bit wonky, isn't all THAT much faster than pure-CPU rendering, requires tweaking of various obtuse parameters (ray buffer size, etc) to get the best performance out of your specific hardware, and last-but-not-least, uses ORDERS OF MAGNITUDE more RAM during the render than pure-CPU (or pure-GPU) modes. Personally, I would avoid hybrid mode entirely. If you need more compute performance, network rendering in Lux using pure-CPU modes is the way to go for Lux 1.x.

    The work in Lux 2.0 is primarily focused around pure-GPU mode, and to a lesser extent, pure-CPU (using the Lux 2.0 RGB-based rendering algos rather than Lux 1.x spectral-based rendering). There is no hybrid mode for the new RGB-based rendering in Lux 2.0. The devs haven't done any active development on hybrid mode in... ages.

    As to Path vs. BiDir: BiDir primarily helps when you have 'difficult' stuff, like lots of caustics in your render. For many renders, this is not the case, and Path can work just fine and converge sufficiently in less time than BiDir.

  • Vertigo789Vertigo789 Posts: 74
    edited December 1969

    cwichura said:
    Keep in mind, hybrid mode has basically been abandoned by the Lux devs. Hybrid BiDir is very broken, and should never be used. If you insist on using Hybrid mode, you MUST use Hybrid Path. Even the Lux devs will tell you this. Hybrid Path (or "mono-directional" in Reality 4 speak) mostly works (there are a few (esoteric) features that are not supported), but is still a bit wonky, isn't all THAT much faster than pure-CPU rendering, requires tweaking of various obtuse parameters (ray buffer size, etc) to get the best performance out of your specific hardware, and last-but-not-least, uses ORDERS OF MAGNITUDE more RAM during the render than pure-CPU (or pure-GPU) modes. Personally, I would avoid hybrid mode entirely. If you need more compute performance, network rendering in Lux using pure-CPU modes is the way to go for Lux 1.x.

    The work in Lux 2.0 is primarily focused around pure-GPU mode, and to a lesser extent, pure-CPU (using the Lux 2.0 RGB-based rendering algos rather than Lux 1.x spectral-based rendering). There is no hybrid mode for the new RGB-based rendering in Lux 2.0. The devs haven't done any active development on hybrid mode in... ages.

    As to Path vs. BiDir: BiDir primarily helps when you have 'difficult' stuff, like lots of caustics in your render. For many renders, this is not the case, and Path can work just fine and converge sufficiently in less time than BiDir.

    Performance is significantly faster for me using hybrid mono than bidirectional with no acceleration. This has been the case when rendering various scenes.

  • jontakacs698jontakacs698 Posts: 2
    edited December 1969

    I purchased Reality 4 and things were going fine until I updated to 4.0.5 or whatever it is and now materials and objects in my scene are disappearing including the cameras. Sometimes it renders as a statue even though I have not selected that option. If I make one adjustment, the scene goes to hell and Lux renders nothing. Is there any way I can revert back to the version before the update? I don't want to create a new scene for every change as it defeats the purpose of saving. Can I just reinstall my first download of Reality 4 and forget about the update for now until the problems are fixed or am I just screwed?

  • jontakacs698jontakacs698 Posts: 2
    edited December 1969

    I purchased Reality 4 and things were going fine until I updated to 4.0.5 or whatever it is and now materials and objects in my scene are disappearing including the cameras. Sometimes it renders as a statue even though I have not selected that option. If I make one adjustment, the scene goes to hell and Lux renders nothing. Is there any way I can revert back to the version before the update? I don't want to create a new scene for every change as it defeats the purpose of saving. Can I just reinstall my first download of Reality 4 and forget about the update for now until the problems are fixed or am I just screwed?

    Okay, if you're having the same problems as me, Reinstall Reality 4.0.2 build 85. This will allow you to render with older versions but the files will still have the same problems once you see them in Reality 4.0.5 unless you render them in an older version (like 2.5). Then, It will recognize the changes as before. Use the earlier build and don't update until they can fix it. Reality is an amazing plug-in/interface with Lux. Try testing with older versions and try your final render with Reality 4. I hope this helps.

  • Gothic ShadowGothic Shadow Posts: 35
    edited December 1969

    I know a few posts ago I posted some renders I did and how they did look a little crappy.(Not sure which post it was but anyway. Could even be farther back.) I want to update that basically and show that now they all look much better then they use to. One below is the newest one I have messed with.

    How_may_I_help_you.jpg
    1200 x 1520 - 821K
  • edited February 2015

    [[FIXED]]
    I left it for half an hour and it un-froze... no idea why.
    I have DAZ (and now Reality) installed on my external hard-drive, but everything else (bar two steam games) runs from there...
    Anyway, working now. time to get testin!

    I just bough Reality (from the Renderosity store because I thought I had a coupon...) but I can't seem to install it. Every time I run the installer and try to set my DAZ installation location, it crashes.

    Has anyone else had this issue?
    running as administrator, running Windows 8.1 and no other issues. Little help?

    Post edited by zededd2000_ec5053ff19 on
  • XenomorphineXenomorphine Posts: 2,421
    edited December 1969

    For those who weren't aware, the fix for geo-grafts is apparently being focused upon for the next update.

  • MrReclusiveMrReclusive Posts: 27
    edited December 1969

    Octane is written for cuda.
    PureGPU/SLG is written for OpenCL.

    AMD cards blow nvidia out of the water when it comes to OpenCL rendering.
    Nvidia uses outdated Opencl drivers and has less opencl cores because they are pushing cuda.

    a Radeon HD7850 (r9 270) is comparable or better then most Nvidia cards.
    a R9 280 or higher is untouchable by nvidia.
    if you get a r9 290x2 you will be rendering a genesis 2 character somewhere between 16 million and 20 million samples a second.

  • kyoto kidkyoto kid Posts: 41,042
    edited December 1969

    ...have an XFX Radeon HD 7950 with 3 GB VRAM.

    For my next build I am looking at the Sapphire R9 290X which has the most VRAM for a Consumer GPU (8 GB). That should be plenty when for when Lux 2.0 releases. The nice part, it is about half the price Nvidia's top of the line consumer unit, the Titan Black.which has 6 GB.

  • StratDragonStratDragon Posts: 3,167
    edited February 2015

    Incy said:
    I know a few posts ago I posted some renders I did and how they did look a little crappy.(Not sure which post it was but anyway. Could even be farther back.) I want to update that basically and show that now they all look much better then they use to. One below is the newest one I have messed with.

    if it's outdoor shot use start with one distant light and rename it "Sun" or use the sun lamp in the Reality props folder

    delete all other lights (Distant lights, Spotlights and Point Lights tend to be incredibly intense for realistic render, use the light props in the Reality folder until you become more comfortable with lighting system.)

    Position the "Sun" light by changing the camera to "Sun" and pointing it at your scene where you want the "Sun" to be positioned in the sky.

    Render using the Linear Kernel.

    ISO 100

    Shutter 125

    F-Stop 16

    Gamma ~ 2.2 - 2.4

    Post edited by StratDragon on
  • Hiro ProtagonistHiro Protagonist Posts: 699
    edited December 1969

    For those who weren't aware, the fix for geo-grafts is apparently being focused upon for the next update.

    This update has now been released and you can download it from your DAZ account. It's version 4.0.7.61.

    Details of changes here.

  • kyoto kidkyoto kid Posts: 41,042
    edited December 1969

    ...just received the email.

    A little frustrated as again nothing seems to have been done to fix the following issues:

    --Materials not showing in the materials tab for older scenes created before Reality4.
    --Issues with render camera flagging.

    Both of these require taking a number of extra steps to correct which strips all Reality information (materials settings and mesh light assignments) from scene forcing the user to manually redo the settings all over again or recreate the scene from scratch as a new scene. This is a serious workflow crippler (particularly in large scenes with lots of objects/characters) as it has been occurring repeatedly with each new update.

    These issues did not present themselves between versions 1.25 and 2.5.

  • TJohnTJohn Posts: 11,099
    edited December 1969

    KK, check your DS to see if it actually installed 4.07.61.
    I downloaded twice to make sure, but the installer self-destructed both times, actually it just deleted itself from the unzipped folder-seems to be corrupt.. I copy and pasted the 4.05 installer.exe to the new folder and it updated successfully. I haven't tested it fully in DS, but the About Plugins is showing the right version number at least.
    [size=4]Caution to All: Don't try this at home. I can't guarantee the results. We should let the "Bossman" check it out first.

  • TJohnTJohn Posts: 11,099
    edited December 1969

    Update: I left a support ticket on Paolo's site, so we should hear from him soonish.
    In testing, the version I'm using now is working, the About Plugins box is showing version 4.0.7.61. And the Changes mentioned in the update email, like
    Added “Keep UI responsive” flag in the Advanced tab
    are there.
    Still, please wait for Paolo. :)
    I rendered this as a quick test. I never tried rendering a toon in LuxRender before. This is Asobi. I think she has skin that makes it look like someone took a picture of a Barbie™. :)

    Asobi2reality_scene.jpg
    1275 x 1500 - 332K
  • kyoto kidkyoto kid Posts: 41,042
    edited February 2015

    tjohn said:
    KK, check your DS to see if it actually installed 4.07.61.
    I downloaded twice to make sure, but the installer self-destructed both times, actually it just deleted itself from the unzipped folder-seems to be corrupt.. I copy and pasted the 4.05 installer.exe to the new folder and it updated successfully. I haven't tested it fully in DS, but the About Plugins is showing the right version number at least.
    [size=4]Caution to All: Don't try this at home. I can't guarantee the results. We should let the "Bossman" check it out first.

    ...haven't installed the latest update to Reality yet.as it does not address the camera and old file issue.The geografting issue means nothing to me as I don't do erotic nudes or even have the genitals as I don't purchase figure bundles, only the base figures.


    I'm basically tired of paying for broken software on my limited budget. 1.25 and 2.5 never had these issues.

    Post edited by kyoto kid on
  • TJohnTJohn Posts: 11,099
    edited December 1969

    I heard back from Paolo. Maybe it's just me, it might be that my Norton is finding something it doesn't like about the installer.exe in the update download. He says multiple users have been installing and using the updates without a problem.
    Sorry Paolo.
    And I apologize to everyone else for being such an alarmist, My bad.
    John

Sign In or Register to comment.