DAZ Studio far from home
marble
Posts: 7,500
I believe that there is a problem (or several problems) when figures are placed far from the so-called World Centre (0,0,0). Could someone explain why and any workarounds?
I tried to create a scene with three G8 figures in a large indoor setting ( Elementary Recreational Facility | Daz 3D ). The figures were standing close to one of the interior walls about +1800 (Z-Axis) from WC. I just couldn't light it and the materials looked all wrong (sharp shadows, high contrast, etc.). I tried with HDRI light and photometric (DAZ) lights - nothing looked right.
I gave up trying and moved them into a much smaller room and changed the storyline around that. Shame because I had other ideas for that big gym hall.
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
For posterity:
https://www.daz3d.com/forums/discussion/537851/fixing-black-forehead-lines-black-eyes-and-red-skin-correctly
Floating point precision has been a problem always (not only in DS) and it is caused by having a limited amount of digits for the numbers.
Lets say there is space for 10 digits, precision is not a problem close to world zero, you can have an item placed at Z = 0.000 000 001 and if you zoom close enough, you can see that it's at that location.
If you then move the item +100 000 in Z-axis, you get only 4 digits behind the decimal point and any numbers beyond those are lost, rounded up or down to fit the four digits behind decimal point.
Some 15 years ago I was modelling ventilation ducts to one of the 'Love Boats', and it was a pain in the behind, as the ship was modelled with the usual (mechanical engineering practice) 1mm as the base unit in AutoCad and the length of the ship was 340 meters (340 000mm).
Ps. 1cm as the base unit is only used by carpenters.
Maybe DAZ will change the default base unit in DAZ 5 although I have no idea how that might affect existing scenes from 4.x.
Is it not possible to move the whole scene, ie characters and the enviroment so that the main action near to the camera is close to 0,0,0. There is no rule that says a loaded environment, large or small, can not be moved.
Yes, by changing the Instance Optimization to Memory.
I made a whole thread about this.
Yep, that's what I tried too. Just a PITA to keep doing that. I haven't got back to it yet because I went with a different room but I will try the solution above next time.
Carrara gets around it with several scene magnitudes, otherwise things vanish in huge scenes
dunno if D|S can do this, it effecively resizes everything
What you've actually described just the opposite, i.e. fixed point representation. In IEEE754, the exponent field tells where the decimal point should be, i.e. it "floats". And an additional bit of precision is gotten be normalizing, i.e. sliding the position of the decimal point until the most significant bit of the fraction field would be 1, and therefore it can be assumed. When a number still cannot be represented in this way, the number is referred to as de-normalized, and it represents the loss of precision you refer to. But even single point FPs are extremely precise.
Floating point numbers are extremely finnicky in that the same two numbers, but calculated via different methods, are not likely to be exactly equal. This is not a real example, but sin( 0 ) would not be equal to cos(pi/2) even though symbolically, they are. It'd be extremely close, but a test for equality would fail.
For that reason, I think it's more likely a combination of the phenomenon you cite, and also the inevitable errors creeping in when a floating point number passes through many calculations, as in several 3D frames of reference from the character's world position through all the joints to, say, the final position of the cornea vs eye moisture. They're both just a little bit off because the standard library that wraps itself around the common math functions can only shield application programs from these errors within a single function, not across the many functions needed to calculate the final position of a vertex.
And I don't know if this would be true for DS, but Blender uses half-precision math in the viewport for performance, so this problem is sometimes quite pronounced until render time.
It's why I makes groups:
1) Actors
2) Sets
3) Lights
4) Cameras
and make subsets for each of the above were it makes sets to neatly seperate them for ease of positioning. eg, A Clouds subgroup in Sets. A Ground subgroup in Sets. And so on.
Then instead of moving the actors to the location on the set they should be I leave the Actors at or very near (0, 0, 0) and move the Sets or Sets subgroups to the position where the actors will be positioned correctly.
You had me checking myself, but found no error in what I described. My description may be simplified, but then again we are simple people
Fixed point is when the placement of the decimal point stays always in the same spot within the number of digits
Floating point, like the name suggests allows the decimal point to be 'floating'
The reason for using floating point numbers is that one can represent both, very large numbers and very small numbers with fewer bits than a fixed point capable of doing the same would use. The flipside is that while it can represent very large and very small numbers, it cannot do both at the same time.
In addition the groups will provide a handy way to hide for example the set when you are working on the figure.
There's a script in this thread that recenters the scene on any item you choose: https://www.daz3d.com/forums/discussion/284301/world-recenter-script-feedback-sought
The issue is programatic, not mathematical. It is caused by the size of the variable used to store the fixed point number. In many programming languages a non-integer number is stored either in a 32-bit variable (often called a float) or a 64-bit variable (often called a double). In this scheme doubles can store FP numbers with a high level of accuracy, but floats can not. I am pretty sure that both Daz Studio and Iray use floats not doubles, Bear in mind that if they switched to doubles, every single vertex would need twice as much data, and so your VRAM and RAM usage would increase very significantly. The render quality however would barely change, so does not justify the increase in data usage. As such we have to live with this far from world zero issue, and use one or more of the work arounds discussed above.
As far as feedback goes, that script is outdated now since Nvidia added that functionality directly to Iray in 2019.
They did? Is it accessible in DAZ Studio?
Yes. As I said, if you change your Instance Optimization to Memory it will shift your entire scene to world origin.
There's no need to use outdated hacks like parenting to a node or using a script unless you use an extremely old version of Daz Studio.
I believe the important thing is to change the setting. If it is already set to memory then you need to change it to speed (maybe changing to auto also works). Then put it back to memory after Iray has recalculated based on the new world origin.
I did notice that, yes. When I was rendering the test images in my thread, sometimes it did not update correctly.
Thanks, I saved it for next time!
That's helpful sometimes, even most times, but it's not a once size fits all solution to what customers do when they set up scenes in DAZ Studio. E.G., parenting to a node still gives the user a way to organize, hide, and show their scene content in a way that's logical to them something that optimizing for memory in iRay doesn't do at all. Also, as some sets are quite large and sometimes actors are at the peripheries of such large sets, I'm not convinced iRay centering the set at (0, 0, 0) is always the right solution for those actors; so Chris's script still has relevant use cases as well. And it also comes down to many designers of a scene wants to have a good grasp of the size, location, and organization of their large scenes so they want to use such things as aids to creating their scenes. I've seen so many blender models that are a long list of mystery part names until you click through each one, locate it, and look to see what it actually is. No thanks!
Enabling "Memory" shifts your scene to world origin at render time, without any user input. It has absolutely nothing to do with how your scene is organized in the scene tree, or the coordinate system Daz Studio shows to the user. It's completely automated, requires no user input beyond toggling the button, and doesn't change anything about your scene.
People keep trying to make this bizarrely complicated, when it's really very simple.
You toggle this button, and the accuracy and quality of your rendering calculations improve. It is a one-size-fits-all solution, provided you're not using a severely outdated version of Daz.
Again, I created a whole thread with visual proof this fixes rendering issues, even when your figures are 10 kilometers from world origin: https://www.daz3d.com/forums/discussion/537851/fixing-black-forehead-lines-black-eyes-and-red-skin-correctly
At no point in any of those images did I change anything in my scene tree, aside from the figure's X coordinate. Changing Instance Optimization does not impact your scene tree hierarchy at all. All your parenting relationships are completely untouched.
Already said this here, but to make sure the word gets out -
@margrave be advised that Iray uses the currently active camera position to determine what becomes 0,0 on its own internal coordinate plane and not Daz Studio's definition of 0,0 for a given scene when a re-centering of its coordinate plane is triggered by eg. cycling through the options on the Instancing Optimization dropdown list. Meaning that in situations where the camera is placed very far away from and zoomed in on objects/characters in a scene, cycling through Instancing Optmization options can actually cause these anomalies (precision artifacts) to show up rather than eliminate them. Scene composition is key.
And as I said there, Iray uses centimeters as its default unit, so it literally wasn't designed for the kind of extreme distances that would trigger that. It's not fit for purpose for the use you're describing.
See this post.
Speak for yourself.
A simplified explanation is often useful, but not when it simplifies to the point of glossing over the very essence of the thing.
Yes, but single precision can float by +127 to -128 bit positions, not by ~32, as your explanation implied. And because of normalization, we get a free bit position. That's why the loss of precision far from the origin is not completely explained that way.
This is where you are wrong. With IEEE754 there is always the same number of bits for precision, unless the number is denormalized. But denormalization doesn't happen with DS kind of numbers. The lack of precision we see far from the origin is being exacerbated by how the numbers are calculated, not IEEE754 alone.
Single precision IEEE754 floats can represent the reals very precisely. They just don't tolerate having a stream of operations applied to them as in, say, calculating the end frame of reference of a series of joints from the hip to the eyelid.
Still don't understand, what are you aiming at and you haven't given any examples to explain your points
A single-precision float has 23 bits for the value, that can represent 8 388 608 consecutive decimal numbers without changing the 8bit exponent value or the one bit sign.
If we now take an item that has location information requiring 0.001 cm precision and we move it 8 388 609 cm off the world center, the 0.001 cm precision in the resulting coordinates can no longer be maintained with a single-precision float