[X3D-Public] X3dom + PROTO
dave at realmofconcepts.com
Mon Nov 9 14:09:13 PST 2009
I'm new to this discussion, but not the concept.
Vivaty made some headway into this proto problem. They actually invented
yet-another meta language to help it out,
but it could be done without that, perhaps using normal x3d meta data,
but basically the idea is:
-Put your 3D content into x3d files. Use little or no script nodes.
(their meta language describes the interfaces, but a proto file could do
just as well)
object-oriented is your friend.
-You need to keep the x3d and js files in sync. This is a slight more
pain than having them in one file (using script nodes), but hey. There
may be work-arounds for that too.
-When the scene loads, your js is loaded into DOM to, on-the-fly. The js
drives the scene. Each instance of the object has its own
data. Thus, you accomplish pretty much the same as protos, without
actually being protos.
This does mean re-working your content, that should not be a shock.
-Composite objects (think protos-within-protos) are possible, more
Question: Is the X3D Consortium planning on a revised spec? Perhaps a
'web' profile? Seems like it should be, as HTML itself
is getting the make-over.
I do hope than anyone and everyone that's ever contributed to
open-source VRML/X3D player will jump in and make
this happen ASAP.
Is anyone working with O3D? Or is it all WebGL?
Joseba Beristain wrote:
> Hi Johannes,
> First of all, congratulations for the great work you and your team is
> doing with x3dom. In my opinion, this could be the key for the X3D's
> future, specially because a plug-in will not be necesary for users.
> I have a question about one think you said in a previus e-mail:
> " X3D reduced to the max: No PROTO or Scripting on the X3D-scene-side.
> All partitioning and scripting is done on the HTML side."
> What does it mean? Does it mean it will not be possible to use X3D
> "files" using PROTO in X3dom? Will exist and alternative way for doing
> the same (or similar) including passing parameters values to "proto
> Probably becouse of my lack of knowledge about this topic, but I
> don't imagine how the partitioning could be done on the HTML side
> doing the same things as PROTOs do.
> Thanks and best regards,
> Joseba Beristain / CIDEMCO-Tecnalia
>>> I really like the HTML5 X3D integration work that is
>>> currently being done. I believe the functionality is going
>>> to be a major step forward for X3D, even if initially only
>>> to bridge the gap for when no plugin is installed. I've seen
>>> it work at SIGGRAPH, and the longtime foresight in creating
>>> XML based X3D finally becomes much more apparent. Kudos to
>>> all involved.
>>> Is there any proposal or consensus on how we should
>>> eventually reference to it in a more succinct and marketable
>>> way? Something simple that would stick (around the likes of
>>> Flash) and help spread the word, or maybe just HTML5-X3D ???
>> The current WebGL-based implementation (X3DOM.org) is really only an
>> experimental solution. It helps to sell our main points to the HTML
>> - Live X3D scene as part of your DOM which allows you to manipulate
>> the 3D content by only adding/ removing or changing DOM elements.
>> - X3D without any plugin or plugin-interface
>> - X3D reduced to the max: No PROTO or Scripting on the
>> X3D-scene-side. All partitioning and scripting is done on the HTML side.
>> This intermediate solution has two major drawbacks
>> - Feature: The current WebGL/Javascrpt layer does not allow advanced
>> feature e.g. (spatial) sound or movie textures.
>> - Performance: WebGL is quite fast but we still have to do all the
>> But the X3DOM architecture is not bound to an WebGL renderer backend.
>> The next step will be support for existing X3D-SAI browser as
>> rendering and animation backbends.
>> The whole design (not the current impl.) was chosen with different
>> backbends in mind.
>> Therefore we believe some single line per (X)HTML document will stay
>> for a while:
>> src="http://x3dom.org/x3dom/release/x3dom.js" />
>> Future version of X3DOM will use WebGL, X3D-SAI, O3D, or browser
>> native implementation
>> transparent for the app-developer.
>> The actually backend will be chosen automatically or based on the
>> content X3D-Profile.
>> Therefore the current HTML-X3D solution should not be called "The
>> webgl solution".
>> "X3D in DOM" or short X3DOM makes more sense.
>> best regards,
>>> IMO, the fact that no plugin is required can make this go
>>> like wildfire. It might just be the spark to light up X3D
>>> like never before.
>>>> -----Original Message-----
>>>> From: x3d-public-bounces at web3d.org [mailto:x3d-public-
>>>> bounces at web3d.org] On Behalf Of Don Brutzman
>>>> Sent: Friday, November 06, 2009 4:58 PM
>>>> To: X3D Graphics public mailing list
>>>> Subject: Re: [X3D-Public] X3D+HTML5 talk presented to HTML5
>>>> working grouptoday
>>>> Don Brutzman wrote:
>>>>> - cochair Sam Ruby was able to run the demos on his
>>>> system without problem.
>>>> his blog has interesting comments
>>>>> Next Tuesday 8-9 am is our regular weekly X3D+HTML5
>>>>> We will review these steps and hopefully craft a website
>>>> as usual Anita is way ahead of us - thanks!
>>>> please also add references to the wiki and the slideset at
>>>> all the best, Don
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> Watkins 270 MOVES Institute, Monterey CA 93943-5000 USA
>>>> work +1.831.656.2149
>>>> X3D, virtual worlds, underwater robots, XMSF
>>>> X3D-Public mailing list
>>>> X3D-Public at web3d.org
>>> X3D-Public mailing list
>>> X3D-Public at web3d.org
>> Dr. Johannes Behr
>> Leiter Projektbereich VR
>> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>> Fraunhoferstr. 5 | 64283 Darmstadt | Germany
>> Tel +49 6151 155-510 | Fax +49 6151 155-196
>> johannes.behr at igd.fraunhofer.de | www.igd.fraunhofer.de
>> X3D-Public mailing list
>> X3D-Public at web3d.org
More information about the X3D-Public