[x3d-public] New volume rendering extension proposals - more work needed

[Ander Arbelaiz]

@Patrick I understand your position and concerns.

So why not simply implement one of the existing 3d texture nodes, instead
> of introducing yet another node?
>
The existing 3d texture nodes should be implemented, I see no reason not to
do so. The Idea of the proposed ImageTextureAtlas is not to avoid the use
of 3D textures.The goal is to provide an alternative and defined way when
3D texture accelerated hardware can not be used. So the motivation behind
the proposed ImageTextureAtlas is not to do it internally. On the contrary,
it is to produce the atlas externally and to define how this atlas should
be provided to the X3D scene.

To generate an atlas internally the same definition can be used, but it has
some constraints:
 - What will happen when you have a large amount of image data in the
browser?
 - How would you precompute the gradient data in the browser efficiently?

Additionally, we see interesting use cases if the atlas is generated
outside x3dom and thus, being visible to the user. Maybe this functionality
is focused on our research activities where we might need interactive
edition / generation / reconstruction of the atlas.



> That’s how other engines do it, and I do not understand why this approach
> cannot be implemented in x3dom.
>
Yes, it can be implemented in x3dom. In fact, I think that there has
already been done a successful attempt to create a texture atlas internally
in x3dom by Andreas Plesch. Also, I have tried this approach outside of the
x3dom library but within the browser, and then linking it with an
ImageTextureAtlas node. Thus, I know for a fact that this approach is
feasible. Obviously, always within the constraints of image processing
capabilities in the browser.

In my opinion, both approaches should coexist and be correctly specified in
the standard. This way, it opens the input options to more content
developers and researchers that might find useful the external generation
of the atlases for whatever reasons they might consider.

@Don Brutzman <brutzman at nps.edu>

> a. Does there need to information in the 18.2 Concepts section?  If so
> what would it be called, Texture Atlas perhaps?  Usually clauses in the
> Concepts section describe general principles of purpose, structure and use,
> especially for concepts applicable to more than one node.
>
I think you are trying to define a more generic atlas node. We should
discuss this by teleconference.

b. If the ImageTextureAtlas is a set of closely related image slices
> stacked together as shown, it is not clear how texture coordinates apply.
>
I agree. I will further describe how each slice can be fetched. As a 2D
texture, globally the same coordinates as a regular 2D image will apply.
However, there is a transformation from 3D coordinates to 2D coordinates in
function of the composition order of the atlas that fetches each slice data
individually. I will describe this process and share a document.

c. Do the image slices have to be related, or can they be completely
> independent, thus using an atlas as a convenient data structure?
>
The image slices are related, but furthermore, the internal organization of
the slices follows a precise definition. All slices in the atlas have to be
equal (height and width). Additionally, they follow an specific order when
they are arranged in the atlas (row-major order).  This definition will
need to be documented.

d. For MPRVolumeStyle, planes do not seem well defined.
>
I agree. DICOM specs defines them better.

e. Images and example scenes would help.


I have a lot of things going on this week. Lets meet face-to-face during
Web3D 2019 and discuss how to follow up from there.

El mié., 17 jul. 2019 a las 14:50, Patrick Dähne (<pdaehne at gmail.com>)
escribió:

> Hello all,
>
> I do not understand the need for an ImageTextureAtlas node, and therefore
> would object to the integration into X3D.
>
> The X3D Volume rendering component currently requires an X3DTexture3DNode
> to provide the voxels. So why not simply implement one of the existing 3d
> texture nodes, instead of introducing yet another node? That’s possible
> even on WebGL. When WebGL2 is available, 3d textures are directly supported
> in hardware. If only WebGL1 is available, it is a trivial task to emulate
> 3d textures by automatically creating a texture atlas internally. That’s
> how other engines do it, and I do not understand why this approach cannot
> be implemented in x3dom.
>
> Best regards,
>
> Patrick
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>


-- 
<http://www.vicomtech.org>

Ander Arbelaiz Aranzasti
Researcher | Investigador

aarbelaiz at vicomtech.org
+[34] 943 30 92 30
Industry and Advanced Manufacturing | Industria y Fabricación Avanzada

<https://www.linkedin.com/company/vicomtech>
<https://www.youtube.com/user/VICOMTech>  <https://twitter.com/@Vicomtech>

member of:  <http://www.graphicsmedia.net/>

Legal Notice - Privacy policy <http://www.vicomtech.org/en/proteccion-datos>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190718/cbe89f27/attachment-0001.html>