[x3d-public] gltf tooling
John Carlson
yottzumm at gmail.com
Mon Jul 15 12:23:38 PDT 2024
DIS and X3D has a wonderful way of abstracting a lot of network processing
away from the application. Just pop a few elements into your scene and
presto, multiuser scenes.
So I would include networking in your low level I/O list as well.
There’s onLoad in the web environment for calling scripts after the scene
is loaded. There’s other events as well.
Understood that PROTOs alone are not ideal. Is anyone else close? Alan
Kay?
John
On Mon, Jul 15, 2024 at 1:45 PM GPU Group <gpugroup at gmail.com> wrote:
> "question of extensibility" "build in an extension mechanism"
> One thought experiment: how to build a web3d browser completely from
> PROTOs - no nodes pre-defined, just load a scene with proto defs for all
> node types at top of scene.
> There are some limitations: hardware / operating system / browser
> environment dependent --like sound, opengl graphics and shaders, mouse and
> keyboard input-- so cheating on this ideal with some built in nodes and
> Browser functions exposed to Scripting would help. But even then, the
> current web3d PROTO system comes up short.
> Cortona - a vrml browser from parallelgraphics- used MS Windows-based COM
> objects for one path to advanced protos. And IIRC had some initialize,
> draw, finalize type functions.
> Octaga browser has an unusual trait: it can run Script node functions
> immediately, without needing to wait for end-of-frame processing.
> https://freewrl.sourceforge.io/tests/29_Scripting/script_call_script.x3dv
> https://freewrl.sourceforge.io/tests/29_Scripting/script_call_proto.x3dv
> Octaga answer = Hello
> (other browsers tested can't do this)
> This would allow the following design: a set of inputOutput fields on a
> Proto are the input parameters, an input_only field operates as the
> function to run, and another set of inputOutput or outputOnly proto fields
> would represent the function outputs.
> (output1, output2, output3) = run( input1, input2, input3 ..)
> And the outputs would happen immediately. This allows Parent-Child
> arrangement of Protos which can recurse deep, allowing protos to emulate
> many of the node type functionally that are currently opaque due to
> parent-child immediate-run needs.
> -Doug
>
>
>
> On Mon, Jul 15, 2024 at 11:53 AM John Carlson via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> Ultimately, the scenegraph *should* be built into the browser or OS.
>> Then there’s the question of extensibility, where X3D steps right in!
>>
>> Instead of arguing about which extensions to support, build in an
>> extension mechanism!
>>
>> Now, how do we do that for XML Schema and X3DUOM so we can validate X_ITE
>> materials?
>>
>> I’m maybe halfway there, parsing X_ITE documentation into X3DUOM. I’ve
>> converted glTF examples to X3D (JSON, IIRC) using Holger’s x3d-tidy, now to
>> actually validate the examples with X3D JSON schema!
>>
>> In the middle of this, I get a whole new system.
>>
>> Sigh!
>>
>> John
>>
>> On Mon, Jul 15, 2024 at 10:06 AM Joe D Williams via x3d-public <
>> x3d-public at web3d.org> wrote:
>>
>>> https://www.youtube.com/watch?v=Z-WTelO-IgU
>>>
>>>
>>> Anyone looking at this?
>>> Thanks,
>>> Joe
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240715/5a760db8/attachment.html>
More information about the x3d-public
mailing list