Feature Request: Torus Component about x_ite HOT 24 CLOSED

In the meanwhile I have seen examples of the short syntax and it is now quite clearly to me how to implement this, and this is what I have already done now.

@jamesleesaunders you can use the short syntax, as you would do it with every other node:

<Torus containerField='geometry'
    angle='1.984163781214606'
    innerRadius='0.25'
    outerRadius='1'
    subdivision='48,48'
    solid='true'>
</Torus>

from x_ite.

Amazingly quick

It's like xmas, loads of presents. 🎅 🎁

from x_ite.

Have you considered to use a prototype to get a torus?

Here is an example of a Torus, which can be modified to get what you want, for instance to implement a angle property.

https://github.com/create3000/Library/blob/main/Prototypes/Geometry3D/Torus.x3d

from x_ite.

You would define the proto within the Scene element before you use it, then add a ProtoInstance element:

<ProtoInstance name='Torus' containerField='geometry'>
  <fieldValue name='minorRadius' value='2'/> 
  <fieldValue name='majorRadius' value='3'/>
</ProtoInstance>

Note: X3DOM does not support protos as far as I know.

from x_ite.

Here are some proto examples form We3d3d.org https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/.

from x_ite.

Yes, a torus proto would be possible and could mimic the x3dom torus. x3dom does now support protos but has the important restriction that the <script> node is not implemented:

https://github.com/x3dom/x3dom/wiki/Prototypes

(It would be very cool if x_ite would support the vrml style 'short' xml syntax <Torus majorRadius='5' /> for instances which is non-standard.)

from x_ite.

Nop, will not implement this 'short' syntax. The ProtoInstance element is well specified and compatible to other browsers. To implement this will lead to a parser change, which is not desired. The parser is cleaner without this syntax.

from x_ite.

Thanks Guys,
Although I am not sure how I would integrate prototypes into d3-x3d (as the while point of the library is we use D3 and JS to generate the X3D - it would be difficult and a little incestuous for D3/JS to generate the <Script> inside the example prototype you sent me.

I have however as a learning exercise had a go at using the prototype and after a lot of head banging I finally got it working:
https://raw.githack.com/jamesleesaunders/d3-x3d/TorusProto/examples/scratch/Torus.html

The issues I was having I tracked down to the self closing tags in the Torus prototype - after eventually swapping all the self closing for separate closing tags it started to work.

This is far from my expertise but would either of you be able to advise how I could implement an angle (start angle/end angle) so I can start to build up donut slices?

Second (possible dumb) question... will/can this prototype be integrated into X_ITE as standard? i.e Adding support for Torus into X_ITE as a standard shape? I would guess from the above this is not an option?
I will therefore need to figure out a way to add Torus to d3-x3d chart library (Prototype for X_ITE, Torus for X3DOM).

Thanks again,
Jim

from x_ite.

Torus.html.zip

Added angle and beginCap, endCap.

from x_ite.

Thank you soooo much! You have been a massive help! I have tweaked your example a little to align with the x3dom interface attributes:

x3dom:

          <Torus angle='1.984163781214606' innerRadius="0.25" outerRadius="1" subdivision="48,48" solid="true"></Torus>

x_ite proto:

          <ProtoInstance name='Torus' containerField='geometry'>
            <fieldValue name='angle' value='1.984163781214606'></fieldValue>
            <fieldValue name='innerRadius' value='0.25'></fieldValue>
            <fieldValue name='outerRadius' value='1'></fieldValue>
            <fieldValue name='subdivision' value='48,48'></fieldValue>
            <fieldValue name='solid' value='true'></fieldValue>
          </ProtoInstance>

I nearly have it but I have one small issue with the start and end angles on the sectors - there is a small gap and the end caps seem to be at a slight different angle. I have tried tweaking the script angles, radius etc in the forEach loops but cant seem to figure out how to 'straighten' the ends?

I also need to figure out default orientation and angles going anti-clockwise (again to match the x3dom behaviour).

Here is my version with Prototype + X_ITE:
https://raw.githack.com/jamesleesaunders/d3-x3d/TorusProto/examples/scratch/Torus.html

And here is a version with Torus + X3DOM:
https://raw.githack.com/jamesleesaunders/d3-x3d/TorusProto/examples/scratch/Torus2.html

from x_ite.

Torus.html.zip

It's more a hack, but it works, to get the Extrusion closer to a circle.

I also added a type attribute with value 'model/x3d+xml' to the Script node, this is important to get rid of browser's parser errors. See https://create3000.github.io/x_ite/dom-integration#script-element

from x_ite.

Because this is a test page, I also added a debug="true" to the <x3d-canvas> element. Now you have a 'Shading' menu item in the context menu, which is very useful if you develop geometries.

from x_ite.

Have now seen this with the orientation in you post. Played around with it, think the values you can use are now equal to X3DOM.

Torus.html.zip

from x_ite.

You are a star! This was an interesting thought exercise for me and I learnt more about Prototypes.
Thanks also for getting rid of the script parser error.

I think it is looking good with both versions fairly equivalent. Hopefully this modified prototype may be of use to you also?

I understand you are not looking to implement Torus into X_ITE and therefore will close this issue.

All that is left for me to do is work out how to weave Prototypes into my d3-x3d library. Or worse case lift and shift the JavaScript you have kindly modified to generate the extrusions.

from x_ite.

Nop, will not implement this 'short' syntax. The ProtoInstance element is well specified and compatible to other browsers. To implement this will lead to a parser change, which is not desired. The parser is cleaner without this syntax.

Yes, the ProtoInstance xml element was invented for that reason, to make it easier and cleaner for a parser (and to make validation for correctness possible with xslt). I understand that parsing would be more fragile and require a lot of work. On the other hand, the existing vrml parser already needs to be able to recognize such new node names (from Protos), showing that this is quite possible, and that it was the original intention.

[For x3dom it turned out that the 'short' syntax was actually the 'natural' syntax and easier to parse. It converts internally all ProtoInstance elements to that short form first.]

from x_ite.

Think you know how to include the proto into D3X3D. But there are also the possibility to use an ExternPrototype.

See http://tecfa.unige.ch/guides/x3d/www.web3d.org/x3d/content/examples/Basic/development/_pages/page17.html.

Maybe this is an option.

from x_ite.

That was quick ! I think that will be a powerful feature.

Is the containerField attribute needed ?

from x_ite.

The containerField attribute is needed because the default value for a PrototypeInstance is 'children' and this cannot be changed. Automatic determination should fail because there are also ExternProtos, which are async loaded, ie. the root node , which determines the type is only later available.

from x_ite.

Makes sense.

from x_ite.

Additionally the root node of the ProtoypeInstance itself can again be a ExternProto which makes automatic determination impossible.

from x_ite.

Amazingly quick - the 'short syntax' works a charm. This is a much simpler syntax and I should I could see this been very powerful / versatile when prototyping new nodes.

from x_ite.

Just a quick update before I close this ticket...

Thanks to your great help I have now implemented a Donut chart in X_ITE:
https://raw.githack.com/jamesleesaunders/d3-x3d/master/examples/X_ITE/chart/DonutChart.html

Which now works almost identically to X3DOM:
https://raw.githack.com/jamesleesaunders/d3-x3d/master/examples/X3DOM/chart/DonutChart.html

With your help using Prototypes + the short Syntax this has meant that the scene nodes etc used to generate both these are identical <Torus containerField='geometry' angle='1.984163781214606' ...- the only difference is that if I detect the viewer is X_ITE I load remote Prototype otherwise it will use the X3DOM native Torus.

Although this was a great learning exercise, I am not sure having to load a prototype from external URL is future proof, as it means I have to bake in the URL of the torus prototype into d3-x3d dist code and it means that I have to find a more permanent location to host the prototype file(s) and should this break / move this will break d3-x3d.

This is how it currently works: https://github.com/jamesleesaunders/d3-x3d/blob/master/src/base.js#L47

My other alternative is to not load the prototype from a remote external URL and bring generate the prototype in JavaScript.
My reservation here is I would have to java JavaScript generate the JavaScript in the <Script> within the Prototype. But at least this removes the external remote Prototype dependency and makes it self sufficient.

My third option would be skip the idea of the Prototype and Torus node and move to generate the Extrusion directly and move the Prototype <Script> JavaScript into being core code.

Thanks again @create3000 and @andreasplesch Have a fantastic Christmas and New Year!

from x_ite.

Cool, looks good!

There is also the possibility to use the ExternPrototype with a data: url and a JS template string.

attr("url", `data:model/x3d+xml,**...proto-scene...**`)

from x_ite.

Brilliant idea! I have swapped the external URL out for a base64 encoded data: URL - now it is all self-included.

jamesleesaunders/d3-x3d@8cc51c5#diff-3aee0dd5fe9ff5da7f2ec8345ee5a46fba1f201a0e2f00cdaa0e4bf299b405cb

And then created a little facility to read a x3d prototype file and convert it into a data url.

I hope you has a great Christmas!
Happy New Year!

from x_ite.