Why does Volume Wrangle change the display of a volume even when it&#3

[magneto]

Hi,

 

I have a color and density volume and I visualize the volume using the Volume Visualization SOP. When I add a Volume Wrangle SOP before the Volume Visualization SOP and then set the group to "@name=color.x", it changes the display.

 

Why does this happen? I don't have any code inside the Wrangle node.

 

What's the proper generic way to modify a group of volumes using the same code? For example you have density, vel, color, fuel and you only want to modify vel, and color volumes using the group parameter and ensure that your code won't modify other volumes.

 

 

Thanks

[jkunz07]

Maybe it's just a viewport display thing?  Have you tried comparing the actual values of the voxels to make sure they don't change?

[magneto]

Thanks John, how can I do that? I thought there is no way to see the values of voxels. Or do you mean by creating points per voxel and then inspect the values. I didn't think of this

[pezetko]

Looks like bug in implementation of Volume Wrangle or Volume Visualization Cd.* interpretation. The blast and merge nodes for groups switch the order of volumes. Best would be probably submit it to SESI.

 

Look at attached file for workaround.

pz_volume_wrangle_blast_merge_issue.hipnc

[magneto]

Thanks I am glad it's a bug so it wasn't my understanding

 

I am surprised someone who almost never uses volumes till now came across this and nobody else. It does make learning a little bit trickier though as I don't know if it's me or the software and I always assume it's me

Edited December 2, 2014 by magneto

[pezetko]

One of the most important thing I was taught is never assume that any program computes something right, always check it.

The problem is not in Volume Wrangle (except the shuffling of volume order) but in Volume Visualization SOP. It requires correct order (x,y,z) as it doesn't check a volume names. So this is rather RFE then bug if I could correct myself.
You can check it by using Name sop to renaming Cd.x, Cd.y, Cd.z to something different (e.g. Cd.x to "a", Cd.y to "b" and Cd.z to "c" and in Volume Visualization SOP set Diffuse Field to "a b c").

Edited December 2, 2014 by pezetko

[Guest tar]

One of the most important thing I was taught is never assume that any program computes something right, 

 

or that the Cpu computes correctly:

 

'Intel Underestimates Error Bounds by 1.3 quintillion'

https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/

[magneto]

Thanks Petr. I think it's still a bug though because the order of volumes change, after Cd.y becomes volume 1, and Cd.x is now volume 3, the Cd.* expression filters them starting from the first volume and in this case Cd.y comes before the other Cd volumes.

 

I might be wrong though

 

@Marty: A major class action lawsuit against Intel is in order

Edited December 2, 2014 by magneto