<div dir="ltr"><div>@Patrick I understand your position and concerns.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
So why not simply implement one of the existing 3d texture nodes, instead of introducing yet another node? 

</div></blockquote><div>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.</div><div><br></div><div>To generate an atlas internally the same definition can be used, but it has some constraints:<br></div><div> - What will happen when you have a large amount of image data in the browser?</div><div> - How would you precompute the gradient data in the browser efficiently?</div><div><br></div><div>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.

</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
 That’s how other engines do it, and I do not understand why this approach cannot be implemented in x3dom.<br></div></blockquote><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div><a class="gmail_plusreply" id="m_-3347503686967255795plusReplyChip-1" href="mailto:brutzman@nps.edu" target="_blank">@Don Brutzman</a> <br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br></blockquote></div><div>I think you are trying to define a more generic atlas node. We should discuss this by teleconference.<br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
b. If the ImageTextureAtlas is a set of closely related image slices 
stacked together as shown, it is not clear how texture coordinates 
apply.<br></blockquote>
</div><div>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.   <br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
c. Do the image slices have to be related, or can they be completely 
independent, thus using an atlas as a convenient data structure?<br></blockquote>
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. <br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
d. For MPRVolumeStyle, planes do not seem well defined.<br></blockquote>
I agree. DICOM specs defines them better.<br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
e. Images and example scenes would help.

</blockquote><div><br></div>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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 17 jul. 2019 a las 14:50, Patrick Dähne (<<a href="mailto:pdaehne@gmail.com" target="_blank">pdaehne@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
I do not understand the need for an ImageTextureAtlas node, and therefore would object to the integration into X3D.<br>
<br>
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.<br>
<br>
Best regards,<br>
<br>
Patrick<br>
<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_-3347503686967255795gmail_signature"><div dir="ltr"><table cellspacing="0" cellpadding="2" border="0"><tbody><tr><td><a href="http://www.vicomtech.org" target="_blank"><img src="http://www.vicomtech.org/firmas/html/Vicomtech209.png" width="209px" height="50px" border="0"></a></td></tr><tr><td><br><span style="font-size:12px;color:black;font-family:CENTURY GOTHIC;font-weight:bold">Ander Arbelaiz Aranzasti</span><br><span style="font-size:12px;color:black;font-family:CENTURY GOTHIC">Researcher | Investigador</span><br></td></tr><tr><td style="border-width:2px;border-color:rgb(0,171,201);border-bottom:2px solid rgb(0,171,201)"><br><span style="font-size:12px;color:black;font-family:CENTURY GOTHIC"><a href="mailto:aarbelaiz@vicomtech.org" style="color:black" target="_blank">aarbelaiz@vicomtech.org</a></span><br><span style="font-size:12px;color:black;font-family:CENTURY GOTHIC">+[34] 943 30 92 30</span></td></tr><tr><td><span style="font-size:11px;color:black;font-family:CENTURY GOTHIC">Industry and Advanced Manufacturing | Industria y Fabricación Avanzada</span><br></td></tr><tr><td><br><a href="https://www.linkedin.com/company/vicomtech" target="_blank"><img src="http://www.vicomtech.org/firmas/html/linkedinCuadrado.png" longdesc="https://ci3.googleusercontent.com/proxy/7UWqpYlE0MQkPCVESbNp1489z7ZFv8EOWuYr1Gq13m6rcg=s0-d-e1-ft#http://Linkedin" border="0"></a> <a href="https://www.youtube.com/user/VICOMTech" target="_blank"><img src="http://www.vicomtech.org/firmas/html/youtubeCuadrado.png" longdesc="https://ci4.googleusercontent.com/proxy/mZe0Yb076jmwB-pTjVqQNp9dWSh9zxI1oShFIED2lNxM=s0-d-e1-ft#http://YouTube" border="0"></a> <a href="https://twitter.com/@Vicomtech" target="_blank"><img src="http://www.vicomtech.org/firmas/html/twitterCuadrado.png" longdesc="https://ci6.googleusercontent.com/proxy/cxi_ZRnSH7REJhce_fO2Cez0OFaQ8d6Ry4oZsIfYvx5M=s0-d-e1-ft#http://Twitter" border="0"></a></td></tr><tr><td><br><span style="font-size:12px;color:black;font-family:CENTURY GOTHIC">member of: <a href="http://www.graphicsmedia.net/" target="_blank"><img src="http://www.vicomtech.org/firmas/html/gmn68.png" longdesc="https://ci3.googleusercontent.com/proxy/pcVRFGl26StF2l-TtLFu85eo3S7dLwbct9EdeuGtPb_5Tx-3dTf_nAPE=s0-d-e1-ft#http://GraphicsMediaNet" style="vertical-align:middle" width="110px" height="38px" border="0"></a></span></td></tr><tr><td><br><span style="font-size:10px;color:black;font-family:CENTURY GOTHIC;font-weight:normal;font-style:italic"><a href="http://www.vicomtech.org/en/proteccion-datos" style="color:black" target="_blank">Legal Notice - Privacy policy</a></span></td></tr></tbody></table></div></div></div>