Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Well, they're popping out even without it. :-) I either turn off the ground plane and do closeups or use a ground plane from Yosemite. With the shadow softness up so very high, the ground plane doesn't seem to do much anyway. Should I be adjusting something?
I don't like the suggested gamma 1.4 setting, though. That washes all my characters out very badly. (I have Gamma Correction OFF). Gamma 1.1 seems OK for my use, or I just leave it at default 1.0. Perhaps the background images are too dark for the lighting. I guess my mileage varied from yours, as the saying goes. I supposedly have calibrated monitors, so who knows. Anyway, I'm enjoying the new scenes and look forward to the fix.
You may notice some Project EYEris eyes in a couple of these.
In these particular scenes the shadows are meant to be subtle, none of them really have any direct sunlight so they are all heavily diffused by the clouds. I always do my best to match the shadows in the render to shadows from objects within the backgrounds so there shouldn't be any need to adjust in most cases. The post I made containing my car render explains how to make the shadows stronger to fit personal preference if the scene calls for it.
Your renders very nice btw, the Felicity renders in particular are looking great :)
The DIM has the update. I've installed it, and I'm pleased to report that it is working great! I think the amount of shadow on the ground plane (maybe mostly AO?) is just right in this image I rendered with the fixed ground plane. This is Urban Storm 3, and this one worked well for me at gamma 1.4.
Edited to add: I meant to say that I appreciate the higher resolution skydomes and the fact that they are not as cartoony as the original Urban Recreation. Thanks.
Using default setting, the shadow will be pretty weak.
Where are all the renders? I really love this set. It is great to have some streets and sidewalks. I have all the HDR Pro sets and I already can't wait for the next one. They are all great.
Just what the doctor ordered. Really, I buy all your sets... this one takes the cake since its one I specifically asked for, so thanks. I would love to see the next set in the series be one that is designed around vehicle usage. I'd love to have one that is in the driving lanes of roads, maybe crossing a bridge, city cruising pictures, a football field, baseball diamond, cathedral... Keep them coming. Rainbows, Cafe's.... I just love these HDR's. :)
Merged with the existing thread on this subject.
You really must let them know thanks for letting all of us freaks out into public.
Is there a knob somewhere that you can use to rotate the dome?
Anyways... you let all my characters loose.. Uh oh :)
Thank you SnoePhoenix! I'm glad you like my new set :)
If you would like to rotate the dome you just have to select the group that loads (DT-UrbamStorm1 for example) then change your Y Rotate value. This will rotate the background and all of the lighting along with it.
I'd love to do some sets more focused on roads, of the scenes that I've done so far from all my sets these are my favorites. Not sure if it's because I like rendering cars so much or what. The logistics of it are a bit weird though because I don't want to be run over, I'm perfectly able to move when a car comes but I would have to put my camera back in the same exact position to resume shooting. Roads less traveled are ideal but they're often less interesting. I'll put some though into doing a set dedicated to a variety of roads and see if I can't pull it off.
Back in the day of Urban Recreation we were cautioned against rotating the skydome and lights. We were supposed to group all the scene items together and rotate that group instead. So now I wonder which sets allow us to just rotate the HDR set. And is there a way to regroup the other sets to handle them by rotating the HDR set group instead of the scene. Can you clarify, please?
UberEnv does some strange things when you start manipulating it. First I have to rotate it in order to get it to line up with my custom skydomes, but when you start parenting it to a group or under a null the rotation values can flip around. I tested it just now to see if it still happens... Added UberEnv, changed it's rotation to -90 X and 90 Y then created a Null and parented it to that. My rotation values switched to -150.01 X, 90 Y and -90 Z. I'm not really sure why it does that...
When I did Urban Recreation I was just figuring out this weird stuff and didn't know how to deal with it. When I made Monterey I found out that locking the rotation values before parenting to the Null kept them from flipping out. So Monterey, both Yosemite sets and this new set are easily rotatable by Y Rotating the main grouping. If you want to rotate Urban Rec the same way you can lock the rotation values for UberEnv, create a new group containing the lights and dome then rotate that.
Thanks for the explanation.
Country roads, mountain roads if your safe about it... I think places without a lot of traffic but are still paved would be the best but your right.. the logistics of it might be tricky but then again, I bet if you give locations.. your happy fans would be happy to scour the region in google Earth to find places with suitable traffic patters... maybe even your own home street if that feels safe to you. Piers at dawn and sunset are always good places and I love the ones inside of churches and other historic places.
Maybe someday we can get a wonders of the world set.. We could get all Lady and the tramp and have a cafe with the Eiffel tower in the background or the deck of a yacht at sea.. Endless possibilities. Thanks for making a great product.
UE2 does read native HDRIs, that is what I have been using since the Yosemite sets. Those two sets and this set have UE2 using .HDR format textures, I noticed .HDR loading when I did my HDRI Gels and it's loading for anything that accepts textures (which means my reflection domes use them now too).
Sorry, double post...
Sorry DT I thought you were still supplying Tiff's for DS. But that thread I linked to is saying that UE2 has got problems and no one will confirm if it has been fixed...very frustrating.
I just loaded on of the Yosemite preset and if clearly says Tiff in UE2 so now I am confused.
That is new to me since I see DS don't recognise .hdr image format and can't be loaded .. so how it can load .hdr other than converted to .tif before ?
Just curious after reading your note about :)
UE2 does read native HDRIs, that is what I have been using since the Yosemite sets. Those two sets and this set have UE2 using .HDR format textures, I noticed .HDR loading when I did my HDRI Gels and it's loading for anything that accepts textures (which means my reflection domes use them now too).
Szark the .tiff's are 32 Bits/channel and still will produce better results than real hdr in Poser for example
one of my true hdr maps produced great indirect shadows ( not confuse with AO ) as long the tiff was created using the real .hdr maps
so that is ok , you will not get better result here when you use .hdr .. see it as IBL on it best
Sorry DT for derailing you thread like this with this conversation but as you know I love to get a full understanding and the only way is to ask people, like yourself, questions. Not to make them myself ;) but to get the best out of the tools we have.
Mec4D I did a test earlier, before going out, with plugging in a HDR from Yosemite in to the Base UE2 and yes it worked perfectly, with no Error messages nothing, call me gob smacked.
Mec4D I never knew that Tiff 32 bit was as good if not better. I have always thought a quality HDRI would have been preferable, thanks again. Indirect Shadows and AO aren't really the problem in UE2 but Direct shadows are but nothing a Distant light won't fix.
the Tiff 32 bits is not better but only a true hdr map will make a difference a map created from many exposures so you don;t need anything else in the scene , it will create also shadows . In DS it is just IBL , the simple version
Btw I don't see how you can load .hdr files in DS other than .tiff converted from .hdr , it don't even recognize the .hdr image format and I use the last DS version
but I don't want to disturb the thread anymore so sorry DT ..
It's okay, I don't mind the conversation lol. It is kind of relevant to how these sets work. I'm not really sure why HDR would not be working if you are using the latest version, support for it was added in 4.6.0.2 about 6 plus months ago.
32 bit TIFFs for UberEnv (created using the included converter preset or other ways) should be 100% the same as .HDR aside from file size and compatibility with other programs. HDR files have the same 32-bit color depth and that is what makes the difference with the stacked exposures, the TIFFs contain the same amount of lighting information from exposure stacking and are able to create shadows exactly the same. The only real benefit end users will see is that the files are smaller for their resolution.
Done in octane :) Preset 5 I think this was.
No. The "32 bit" in an hdr file usually means 32 bit RGBE encoded, that means 32 bit for one pixel, which is 24 bit color and 8 bit value. The "32 bit" in a 32 bit tif on the other hand means (most often) 32 bit floating point per color channel, which results in 3*32 = 96 bit per pixel for all channels (R,G,B). They both have (almost) the same dynamic range, but tif has many more colors (and is 3 times as large without compression).
DS passes any hdr on to 3delight, but the textureconverter of 3delight, tdlmake only accepts hdr files with a RADIANCE signature (first line of the file). That might be a problem, e.g. ImageMagick outputs hdr with an RGBE signature.
I knew I read an explanation of what exactly was up with that...but it's nowhere near as concise as this one. It explains a lot of the behavior of tdlmake and why some work and some don't.
You are right that the 32-bit TIFFs spit out by the UberEnv preset are floating point. The slight exposure difference matters most in post processing and it obviously matters in the ability to cast shadowing in renders (though not as much) but you have to consider the input information too.
For the slight increase in tonal rage from an HDR to matter it would have to be taken advantage of and I'd say the majority of times it isn't. Doing exposure stacking the usage of tonal range comes directly from the number of images used. When you download an HDRI from the internet it will most likely be made from 3 exposures because of the consensus that this is the minimum (which is even more likely if it's high resolution), it's less likely that the HDRI will be done with 5 images and less with 7 images etc. Even those 7 images probably wont reflect the possible tonal depth of an HDR, or a 32-bit Floating Point TIFF (7 exposures are what I use for the HDRs in these sets). From what I've come to understand 15 exposures is the upper threshold of bracketing and I don't believe the HDR format would actually benefit from more than that, but I could be wrong and the number/quality difference obviously depends on bit depth of the original images (14-bit RAW etc). I know that there are cases where way more bracketed shots are put together like astral photography of nebula etc but I believe that is a different format and process
If you were to convert one of my native HDRs from this set having been made by 7 exposures to 32-bit Floating Point TIFF I really believe there would be 0 technical differences, because the tonal depth doesn't reach the limit of either format. Any extra color depth in the TIFF would be extrapolated and wouldn't be based on real life information, it'd come from the original information and would essentially be the same. It's like blowing up and image then shrinking it down to it's original resolution.
There are some different situations like rendered HDRs from programs such as Vue like my Skies Of sets, but these still rely just as much on actually taking advantage of the tonal depth. A lot of the time I've fount that Vue really doesn't, most notably in the brightness of the sun (low exposure values on the sun in real life are are brighter than Vue seems to think they are).
Don't stop discussing this now, I have got my pop corn and reading with interest, Learning so much my head may explode at any time.
Yes, keep going, I've got mypopcorn and am watching Szark's head, wondering if it will explode ... ;)
hey quiet in the cheap seats. :)
*lobs a peanut from the gallery ...* ;)