We are getting weird renders in this latest beta. (2.1.6.49730) Low densities (and possibly any other channels too) are rounding off to zero before they are sent to the renderer. So old files render differently. Particle rendering. Prt volume with either a magmaflow or krakatoa material.
How might one go about making this happen?
I submitted a ticket for this today. The issue probably isn’t related to rounding, but to 2 other issues, one being the one in my ticket, the other being that Krakatoa returns the image without error. Seems like if the Magmaflow was throwing errors like we saw for the viewport, the render should have too. As is, we just see the result of the error in the render and only thought something was wrong because the artist picked up on the change. If the render threw an error from Magmaflow, we would have found the first bug sooner.
Oh, tried my workaround (changing from float16[3] to float32[3]) and it doesn’t work. The Magmaflow errors again (same as before) and the render completes as if the Magmaflow was not there. Seems to be related to InputTexmap. When I remove that node everything seems to work fine.
I’ll see about creating a clean file for this report. It looked like the issue affected a file using loaders instead of volumes too. No texmap inputs. I’m not sure what’s going on because PD viewer reports false negatives. I don’t trust the display of maxscript to report float values correctly.
Here is a file. you can easily see the rounding. Multiply by values < or = to 0.5 (for this scene) and densities round to zero. I tried bumping up the channel to float 32 or float 64 but that has no effect.
Frame 0 multiplier is 0.5 and nothing renders even though particles are generated.
Frame 1 multiplier is 0.5001 and everything pops back into drawing correctly.
krak_2.1.6_roundingError.zip (36.4 KB)
If you replace the InputChannel Density with an InputValue Float, you can see the same thing happening.
So 0.0001 * 0.0001 = 0.0, even if Out:Density is float64.
[code](–MAGMAFLOW2–
global MagmaFlowEditor_EditBLOPHistory = #()
node0 = magmaNode.createNode “Output”
magmaNode.setNumNodeInputs node0 1
magmaNode.setNumNodeOutputs node0 0
magmaNode.setNodeProperty node0 “channelName” “Density”
magmaNode.setNodeProperty node0 “channelType” “float64”
magmaNode.DeclareExtensionProperty node0 “Position”
magmaNode.SetNodeProperty node0 “Position” [90,140]
magmaNode.DeclareExtensionProperty node0 “Selected”
magmaNode.SetNodeProperty node0 “Selected” true
node2 = magmaNode.createNode “Multiply”
magmaNode.setNumNodeInputs node2 2
magmaNode.setNumNodeOutputs node2 1
magmaNode.setNodeInputDefaultValue node2 1 0.0001
magmaNode.setNodeInputDefaultValue node2 2 0.0001
magmaNode.DeclareExtensionProperty node2 “Position”
magmaNode.SetNodeProperty node2 “Position” [420,60]
magmaNode.DeclareExtensionProperty node2 “Selected”
magmaNode.SetNodeProperty node2 “Selected” true
try(magmaNode.setNodeInput node0 1 node2 1)catch()
magmaNode.setNodeInput node2 1 -1 1
magmaNode.setNodeInput node2 2 -1 1
)
[/code]
EDIT: Oh, now I see. It’s passing float64 to the renderer which is reading float16. So if we change the renderer to float32, it’s fine.
EDIT: This behaviour is for both 2.1.2 and 2.1.6. I think it would help (a lot) if the PDV and Debug views would show smaller floats. Right now they show 0.0 when it’s clearly higher (but still tiny, just below the threshold that maxscript will show).
Chad that leads me to ask is there a switch to get max to display ten thousandths?
Not that I know of. Bobo obviously knows more than I do about this, but I would assume you would have to actually output strings in the PDV or Debug in order to show the values.
Ah silly me it is a general pref setting, spinner decimal precision, I knew I had seen it somewhere it just didn’t click. Should have looked harder before I asked.
New Years resolution… screw head on at least a little bit straighter.
That affects spinners, but not MAXScript in general. I thought you meant in the Listener.
I was thinking that may be it I generally have such issues when using box#3, I end up scaling a value, manipulating it and then returning it to needed value.
I got a little sidetracked.
If I change the PRT Volume subdivision to 11 it renders at frame 0. Am I missing something crucial when I do that? You are simply halving the density right.