Adding to Cart…

Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
I just want to let you know that all my renders in my gallery are rendered in 3Delight and most of them just with two lights, one AoA Ambient and one AoA Distant (expect the very old ones) but every render in the "new releases" and also a lot in the "some older renders" are with these AoA lights in 3Delight. I do not use Iray.
Yep, 3delight is very much alive, especially for those of us that don't have "Killawatt-Hog Graphics Cards", lol.
Oh, and you do have some very nice renders in your thread cosmo71.
A little bit of a wip, at Progressive scan at that. I'm toying a bit with sneaking light in and around that "Elven Temple", a long way to go still.
Hihihi. Cool!
And this is just awesome
http://www.3dtotal.com/index_interviews_detailed.php?id=272#.VMjk3i49VqF
Some extra lovely work in your gallery, Cosmo!
----
Cool indeed!
As for the interview... "relatively inexperienced" my [AYEM]. Okay, it probably helps having a loved one around who actually shares your passion for 3D, but. But. They're insanely talented.
Yeah, Much more so considering all the textures are hand painted (not based on reference photos). The characters are very stylistic, so they don't look real. But the shading is wonderful. I personally like seein all that rich skin variations details (on the male model). I'm guessing they're painted. - either into the diffuse or control maps. There's an article in Vertex 1 books/magazine about that - http://artbypapercut.com
But hey, they're using MARI which makes painting those kind of details much, much easier.
I wonder what they use 3delight for? Probably for displacements, since Vray is very slow and not as flexible at displacement.
Tried the beta DS4.9.
Oren Nayar is still only available as a specular BSDF. Diffuse brick is still Lambert Diffuse. So no changes there.
Render settings for 3delight is the same (Progressive - Off, Gamma Correction - Off, Gain/Gamma - 1.0). I'll check performance later on.
Edit:
Some performance data:
DS4.7 - 17 minutes 4.77 seconds
DS4.9 - 15 minutes 53.19 seconds
Scene is an earlier version of the room I posted. No SSS, just diffuse, specular and reflection/refraction. Not much of an improvement, but it's there. Ray trace depth was 4, shadow samples 16 (default). Haven't tried anything higher.
Thank you for the report, Wowie! Sad the Oren-Nayar miscategorisation hasn't been fixed.
The DS changelog says it's 3DL 12.0.27, and on the one hand it's great to have a very recent 12 build, but I hoped it was going to be 12.0.28 (with better GGX/GTR sampling).
I need to research more about MARI. I know that Substance Painter has infinite possibilities, what with it using procedural 'substances' and particle brushes (oh how I love them), but using SP to build impressive procedural skin seems to require creating/finetuning custom tools; out of the box it appears to be primarily geared at non-organic materials. I wonder if MARI is different.
One thing to remember...it's just the first beta release...there should be at least one more of those before it goes 'live', so there is still time to fix it.
Maybe need to prod the 'front office' again?
Totally.
MARI basically lets you paint textures directly onto surfaces in a realtime preview viewport with an approximation of your renderer's shader. In effect, it's like being to able to paint textures (color/diffuse, roughness, specular, normals, bump, displacement etc) in an IPR session. Unfortunately, it's not cheap. MARI 3 was recently announced - comes with realtime shaders of Arnold, Vray and Redshift (no Mental Ray or Iray).
3DCoat is another alternative.
Youtube doesn't like my mobile connection - but from what I gleamed, the workflow idea is basically similar. The painting window updates your multi-channel textures (driven by your 'substance' files that provide diffuse/height/roughness/etc channels for every brush stroke, and modulated by the brush alpha) applied to a phys-based shader (in SP, you can choose metallicity or glossiness-based ones, or import a custom one). You can also have filters, layers, all of them interacting with each other and your mesh geometry ('smart materials'). Everything is updated real-time. Then you export maps - I saw Arnold-specific presets in my SP output, for instance.
What's most interesting to me is what tools exactly are there. Material presets, brush types, etc.
I saw MARI indie on Steam, which looks theoretically affordable (in my case, there is also regional pricing), but I'm just not sure that for someone like me it's a worthwhile investment, if I have Substance Painter _and_ Blacksmith3D already. I need to find a MARI manual to read carefully.
Let's plan the attack then, and maybe recruit more forces?
...all these things, and they're busy sticking some sort of DRM in. And the dzQuaternion class may still be broken for all I know!
I'd be happy if the spell check would stay on, lol. Given all that mention thus far, not to say other stuff that I'm not sure about yet (UE2 map offsets), that sounds like more then just a few things.
Captain Dallas, (Sighs) "What else?"... lol.
(EDIT) I guess it was the map, doesn't happen with a plane black image in the color slot. Curious.
errr, what just happened? set the UE2 at 60% strength with no map, and it looked, OK.
Then make a plane Mid Gray (128R, 128G, 128B) map in MS paint, and UE2 explodes.
Is the map somehow messing with the intensity, if it is at mid gray? Or is something else going on?
Technically you don't need them. They just make things easier. I know some artists still prefer to manually paint things in GIMP or Photoshop or use specialized tools like Knald, Xnormal or Crazybump. Or something like Quixel Suite (with Phooshop) that has a Hobbyist/Freelancer pricing. If you don't have Photoshop, I'll say 3D Coat is the best alternative. The educational license is just US$ 99 and targets hobbyists and amateurs. I don't think there's restrictions like Blacksmith3D or MARI/Substance Live indie and it comes in Windows, OSX and Linux versions. Already been thinking about buying it for awhile.
Just finished checking if raycache is being passed or not. Big surprise! It's not.
I think rendering a RIB and sending it to the standalone is still the best option for now. You can reap the benefits of the new renderer versions, improvements to shaders if they are made to take advantage of newer things and generally less unnecessary memory usage for the app and more for the renderer. Not to mention i-display options of outputs.
Oh yeah. FYI, an IDL render of that scene with raycache enabled via Kettu's script takes 36 minutes 57.50 seconds. About the same time, it was roughly 60% complete with the 4.9 beta.
The other thing with 'MARI' that I vaguely remember, was UDIM. If your making Genesis 3 maps, UDIM support I guess is rather important.
Although as wowie pointed out, not all of us are shacked to UDIM or have endless budgets. If you do that for a living and need Hollywood class details with thousands of maps per surface scanned in from photos of a movie set, MARI is a contender.
http://www.thefoundry.co.uk/products/mari/?gclid=CLTvmqbyrMYCFYU9gQodGCEJzw
Me, I need to remember that GIMP dose not expand the window if a map is larger then the view-area, lol. Ms Paint from Windows 98se is preferred over the later versions that altered the functionality of some fundamental things in a not so helpful way. And I'm not making people for movies or games.
Probable MARI would easily be able to take my test chamber, and produce a UE2 map in a breeze, rather then me toiling over graph-paper for a few days, lol. Then again, probably allot of other content creation tolls (blender, z-brush, etc) can make lat-long maps as well and capture the light reflection level off a polished floor.
wowie, I don't and won't have 4.9 installed so I can't check it (don't have enough drive space at the moment to devote to the beta). But if 4.9 is slower than 4.7, even with raycache on, then there is something else going on, because the 12.0.x series is much faster than 11.0.131, for the standalone. Most of my runs of the same RIBs were at least 10 to 15% faster with 12.0.19 than the last 11 standalone. Unless there is a regression bug in the version in Studio 4.9 it should be faster, raycached.
Yeah. I know. Regression happens, but the times I'm seeing are way too high. I eyeballed the two shots and didn't find any noticeable difference. Didn't run diff on them or anything though. Might be worth asking if any of the people at DNA research aware of a regression bug. I'm guessing it's DAZ Studio rather than 3delight.
As for DAZ Studio 4.9 itself, nothing really impress me so far. The raycache problem just killed it for me. But I'll file the report, just in case.
It's beta, so there probably is 'hooks/trackers' (Debugging code) stuff in the beta for diagnostic stuff. 4.8 started out slow for some things near the first public beta, than got faster as updates came threw (presumably as sections of debugging code were disabled in the build).
Although, the Studio-3DL interface may also not be as fast as the standalone option. How much of the render time in the standalone, is considering the compute power to send the scene from Studio to 3DL, food for thought.
Using scenes that don't require much precompute overhead (no AoA shaders), but are big enough/complex enough to give a decent render time...and the results are pretty much consistent. Usually, without AoA shaders, only the first time does the image optimization matter, so disregarding that run you can average several runs in Studio and in the standalone...which is what I usually do with each update.
The render times are for rendering only and does not include preparsing or preparing files. So DAZ Studio itself shouldn't interfere that much. With just ambient occlusion, DS 4.9 beta was actually a bit faster. That's why when it crept past the 40 minute mark, I know there's something not right. After three renders, with restarting the app and the computer and ending up with the same render time (give or take a few), I'm pretty sure it's a genuine problem.
Never saw such a drastic difference with the other betas though.
The bigger issue isn't that. It's that DAZ Studio still does not have an Oren Nayar diffuse brick, GGX/GTR specular brick, raytraced subsurface scattering and does not pass raycache parameter as it should to speed up rendering. The app is capable, the renderer is capable. but it's just not enabled. Ray caching is essential for stuff like GI and photon mapping. Until that's enabled by default, there's little point of doing the more advanced stuff like reflective/refractive caustics.
But then again, we are talking about a 3D app that doesn't enforce linear workflow by default. At least for 3delight anyway.
What's that Indiana Jones analogy? Bringing a knife to a gun match.
True, very true. I was also thinking of all the 'Status' things that are in studio for the render as well, not just the shader export stuff. And if it all has debugging code in it, it's going to be slower even if the root 3DL is the same, lol.
The raycache is probably the easiest to do...that should just be a one character change in the render scripts (even the default 3dl render is 'scripted', just not like the 'scripted render' items).
Oren-Nayar is probably a couple of lines of code and a recompile, but needs to be done in the source. The GGX/GTR might be a little more than that...but essentially the same process. It's just a matter of updating the existing stuff to access the new features. Stuff we can't do, after it's compiled and packaged.
What times do you get when you export the scene as RIB and feed it to the standalone? If they are more normal, then something went wrong with the DS-specific 3DL build. If not, then something must've been changed in the DS script...
The only restriction about indie Substance is annual income of less than a hundred thousand dollars. Used to be less than ten thousand, but even if we take my real-world job, I'm not making even remotely that much per year, even when rouble/USD exchange rates were better, so I was clear even back then.
UDIM support is planned for Substance Painter, BTW.
Downloaded the beta... haven't rendered anything yet, but looking at the RIB everything should be fine. All the Ri stuff gets passed correctly.
Another thing may be a shader issue - Wowie, were you using UE2 for GI? Does anything change if you swap it with my GI shader?
Oh BTW. If we are going to try and bug customer support with our shader mixer related requests, maybe it's worth it to ask for light category support added to UberVolume.
Haven't tried exporting to the standalone yet. Based on mjc1016's experience with the standalone, I pretty much doubt the renderer is at fault here. Exporting to RIB is quick, though I did not do a comparison with 4.7.
Yes. I'm using UE2. Haven't tried your GI shader on that scene.
UberVolume is, or rather was, omnifreaker's product. I doubt they will bother changing it if up to now they haven't changed something they can do themselves (like those bricks in Shader Mixer or even the app itself for passing raycache parameters).
What I mean is that maybe something went wrong during compilation of 3DL binaries for DS. I remember there once was a quirk in one DS build that wasn't there in the standalone that had the same build number.
Please keep us posted.
Didn't DAZ buy UE2, UberVolume, UberArea and the first UberSurface out? Then they should have the source code and could change it.
It gets funny how default lights have categories now but the only pre-built shader that supports them is AoA's EZVolume.
For most shaders, it's not a difficult thing to add, but must be done in the source code.
Well, DAZ reps on that beta thread says that tickets are handled faster now.
I've already listed mine - Oren Nayar and raycache support - there. Maybe both of you can submit your own ticket and post it. Let's see if those tickets gets handled faster with more definitive answers than just 'forwarded to the dev teams' or 'we are aware of this'.
I had an Oren-Nayar ticket, would you say I need to make a new one or just remind them of the old one?
Hey this may explain the slower renders...
http://www.daz3d.com/forums/discussion/comment/937792/#Comment_937792
I suppose that there are ways to include a throttle.
Could be, in theory.
I know that I have had scenes taking around an hour to render - interesting that they all had The Girl 3 in them, and possibly subdivided - that would drop to way below 50% and chug away like that for quite a while before picking up again. In both DS build and the standalone. I chalked that down to using a bucket too high (either 256 or 512, I don't remember) which could mean stuff getting paged to HDD and hence slow to retrieve. But maybe it was something else.