-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No way to use TextureVolume on transformed texture? #418
Comments
We are about to add 3D texture transformations for the volume texture (similar to the existing 2D texture coordinate transforms for |
Ah, 3D texture transforms could indeed solve this, albeit in a bit convoluted way when the slicing geometry has a complex transform. As it looks like the current Having Best of both worlds would be to specify the slicing geometry and volume both in world-space to allow maximum freedom. But I'm sure that has both performance and design downsides. I guess being able to set a 3D texture transform on the |
The plan is to have both: lookups in object-space, plus 3D transformations (as 3x4 affine matrix, including translation). This should work nicely as long as the manipulation (like orientation) of the slice geometry is done via vertex position updates (or updating the plane equation) and not via an |
How about a matrix parameter on |
Volume texture look-ups are now in local objects space, and materials have 3D texture transformations. |
As using a
TextureVolume
is the new way of slicing I was wondering if the 2.1 API currently supports slicing only in a fairly limited way? I.e.TextureVolume
takes aVolumetricModel
reference, meaning it can only access the untransformed original volume extent. So any geometry to be colored by aTextureVolume
must be located in the same untransformed volume extent. The docs say[t]he volume texture type implements texture lookups based on 3D world coordinates of the surface hit point on the associated geometry.
I read this as the sample position on the transformed geometry (i.e. Instance) is used, and not the untransformed geometry (i.e.Geometry
). But that implies slicing geometry placement is limited by the untransformed volume extent and a geometry cannot be moved without influencing the volume-based coloring.The use case I was thinking of is having multiple copies of the same volume data side-by-side in camera view, but with each volume instance showing a different slicing geometry in its extent (alternative use case: using the same slicing geometry but with different volume datasets side-by-side). But the world-space placing of the slicing geometries cannot be matched with the untransformed volume extent so the use case is currently impossible to realize.
Just curious if my conclusion is correct here?
The text was updated successfully, but these errors were encountered: