[X3D-Public] Fwd: Re: [X3D] X3D HTML5meetingdiscussions:Declarative 3D interest group at W3C

Sat Jan 1 23:21:47 PST 2011

Hi,

Am 01.01.2011 23:46, schrieb Joe D Williams:
> HI Philipp,
> In a previous mail you mentioned integration of 2D and 3D. For an
> overview of this kind of stuff please look at the X3D spec to see the
> wide range of 2D and 3D objects along with single and multipleD static
> and streaming texture objects supported by several X3D free and
> commercial implementations.

But if we are operating in a Web context, then there is no immediate
need for these parts of the X3D spec as HTML has (quickly growing)
support for these media types already. We do not want to reinvent the
wheel here but reuse what is there and maybe help to improve it or
tailor it for its use in 3D, where necessary. This is the key difference
between past X3D and XML3D, we do not to impose our rules on others but
work with them as collaboratively as possible.

> For a long time it has been easier to get html and svg renderings and
> other texture types usable in 3D browsers than to have 3D in running in
> the html document.

But this is a very different approach that collaboratively working on a
joint 2D and 3D declarative model for the Web.

> I hope all can spend some energy understanding what has been and what is
> here now so we get concrete specs for basic deliverables,
> implementations of that feature set, and standardization. Now we need
> reliable abstract definitions for this nD+1 functionality that just
> simply must work everywhere in our WWW.
> 
>>  (e.g. XML3D spec on xml3D.org),
> 
> I think I see it, but please take this hard-earned lesson, details of
> the fidelity of  behaviour is very important. What I saw did not speak
> to this point, or  many others concerning how the thing actually runs. I
> think it will help to disclose more abstract and concrete ideas about
> how XML3D is supposed to operate when the show is live and producing
> work by generating, sending, and receiving events that change the
> pixels. The X3D SAI abstract spec covers this for X3D processors in some
> detail.

Well, we are at the point where we are considering, if there is even a
need for implementing/emulating some sort of the event cascade for 3D
rendering. I am rather skeptical at the moment. So for now we simply use
JS scripts for everything. It not actually that hard. You simply create
lists of callback that trigger from certain events. Its all hand coded
right now, but you can easily envision some library that help us manage
these in some more structured form.

Implementing the cascade event model seems to be hard in the first place
and might not resonate too well with the Web side of things. So before I
go there, I want to evaluate all options that are more "Web-like".

With the event cascade I would like to go back to the drawing board and
really try to understand what key mechanisms are implemented that way
and if and how we can map them to the Web-like model. I believe we need
to go back and see if there are other models to implement the same
functionality. It will not be easy as it is the main mechanism there is
in X3D and so of course people tend to "think" in this model.

> btw At first glance the spec shows me a radical dependence upon style
> sheets - even to "depreciated" the 'transform' in the 'group' element.
> That is great thought but like html, I think basic stuff  shall be that
> it works (everything does something default without CSS). But hey, it
> looks like all the latest connections.

Again CSS is the way things are going on the Web side of things. Our
main aim has been to see how close we can bring the two sides. It turns
out that you can bring them very close indeed (and actually reuse big
parts that are there already again, like the 3D transformations in CSS
with its animation support, etc.).

However, there are some drawbacks. The CSS model of 2D layout of object
in some constrained 2D rectangle does not really apply to 3D, where we
tend to position objects with absolute coordinates but relative to some
parent coordinate frame. However, this is perfectly possible with CSS as
well.

Also there are limitations in the JS model of CSS, where we do not get
callbacks when CSS attributes get changed and so will not be able to
update the WebGL rendering in turn. But this does not affect our native
implementations (just the JS/WebGL version). This is why we still need
the transform attribute for this version. We may decide to keep it
around nonetheless.

Finally, CSS for 2D uses a fixed function "shader" model, where all
attributes are known and fixed. This is in stark contrast with
programmable shaders, that can have arbitrary attributes or almost
arbitrary types. The way we went here is to separate the specification
of the shader (as a distinct object in the DOM) from its assignment to
some geometry via CSS using its URL (fragment).

Finally, let me say that I am very happy that we got to the point where
we can discuss the technical issues at hand.

	Philipp

> Thanks Again,
> Joe
> 
> 
> 
> 
> 
>> but let me
>> try once more to at least get an open mind from you and I will shut up
>> in this thread afterwards.
>>
>>
>> I fully respect your believe that X3D is the best declarative technology
>> for 3D. It may be in the way it was designed. However consider the
>> following analogy (I know its not perfect but bear with me to get my
>> point across):
>>
>> If you want to transports good across water you build some sort of ship.
>> If you want to do the same on land (Web), you build a truck. Different
>> environments demand different solutions and each one might be "best" in
>> its environment. Trying to use ships on land is not going to work too
>> well. While some design decisions will be very similar (building strong
>> structures to hold the goods), others (like the rudder) do not apply
>> well in a different context.
>>
>> So to repeat my point from earlier: You can decide to stay on the water
>> and ignore the Web. You can try to convince people to build canals and
>> locks instead of streets (good luck with this!). You can try to convert
>> the ship into an amphibious truck by adding wheels (X3DOM), or you can
>> start with an existing car that drives well on land (Web technology) and
>> optimize it for transporting goods (XML3D).
>>
>> As you know, I prefer starting by optimizing the car as I see it as the
>> best option in the long term. Most car technology people are developing
>> anyway (streets, filling stations, etc.) will immediately be useful for
>> trucks as well. Car drivers will have a very easy time to learn driving
>> truck, etc., etc. Yes, it also means that we cannot use the same ship
>> ports for loading trucks (a big advantage for the amphibious trucks!).
>> However, at the end it might still be worth designing trucks starting
>> with cars, in particular as cars are already a big business (much bigger
>> than ships). Others may see the situation differently and make other
>> decisions, though.
>>
>>
>> Here is the point I want to make: We have come to the ship yacht to
>> learn if there are ship building techniques that could help us build
>> better trucks. I am sure there are. Answers like "but ships are working
>> great, you really need to build a ship" are well understandable but not
>> very helpful.
>>
>> I am still hoping to find some ship builders that would be willing to
>> engage with us in technical discussions, start looking into our early
>> blueprints (e.g. XML3D spec on xml3D.org), test drive some of the trucks
>> (also at xml3D.org), and show us where the break so we can fix them.
>>
>> Along the way we may even invent containers that help us move the same
>> goods very easily on BOTH -- ships AND trucks :-).
>>
>>
>> Philipp
>>
>>
>> Am 31.12.2010 11:46, schrieb GLG:
>>>> Things are not as easy as they sometimes seem to be.
>>>
>>>
>>> Philipp, This is our point exactly. Many of the things that
>>> are discussed now we have gone through in the past at one
>>> point or another. A lot of it is documented and available on
>>> the Web. The consensus of years of debate, arguments and
>>> compromises (by many more talented people) resulted in what
>>> we have today. If we have ROUTES and PROTOS ETC ETC it is
>>> because they were needed/wanted. Not everyone agrees to
>>> everything, but that never really happens anywhere.
>>>
>>> It seems your main arguments against a lot of it is that, it
>>> cannot be done, or you cannot include it, or it will not
>>> work inside or together with HTML. Perhaps, the reason for
>>> this is that it doesn't belong there (Len said that too if
>>> you recall). I have never tried to put a movie inside a
>>> book, or, worse yet, a video game inside a newspaper or a
>>> magazine picture (as in a 3D media into a 2D container),
>>> because I know the chances of that working well are very
>>> small. I could rig a book with hardware and say "-look it
>>> works", but then I won't really have a book anymore. I will
>>> have a contortioned device masquerading as something that
>>> would be neither a good book nor a good video game. Or, I
>>> can put a hologram picture in a magazine and say "-look I
>>> have an interactive 3D mag" but do I, really?
>>>
>>> Notwithstanding the validity or even the exact relevance of
>>> the above examples, or lack thereof (that is beside the
>>> point), and not meaning to be sarcastic either believe me, I
>>> am trying to represent what some of us are trying to say.
>>> You obviously have some time invested in XLM3D, but,
>>> honestly, that pales in comparison with what we have
>>> invested in X3D, and this by a very large margin. You talk
>>> about the large number of people already using this or that
>>> technology on the web, but there are not the 3D experts now
>>> are they? X3D was put together the way it is because that's
>>> what works best. You wouldn't want to get all of those
>>> internet users on the wrong path now do you? If all of the
>>> people who have contributed to X3D over the years would be
>>> here now at the same time, with all due respect, you would
>>> get buried, deep. XML3D is your baby and you love him, I can
>>> understand that for its own merits, innovation always has
>>> merits, but X3D is our grandchild, and we are very proud of
>>> him too. It wasn't always easy, but he's now a strong,
>>> reliable and mature individual (figuratively speaking of
>>> course).
>>>
>>> To me, it would make a lot more sense to render HTML inside
>>> a 3D scene than a 3D scene inside HTML. X3D can already
>>> supports multimedia assets such as sounds and movies. How
>>> far are you planning to get with XML3D? Seeing HTML inside
>>> X3D is one of my dreams, not the other way around. But, if
>>> you insist, please develop support for a core X3D Profile
>>> with a clear upgrade path (to paraphrase Joe - but probably
>>> not going to happen, like Len said - that I wonder why, I
>>> really do). The standards have already been defined. There
>>> is no need to re-invent 3D. I can only support XML3D as a
>>> step up to X3D. That is the only way what you are doing can
>>> make sense to me. Otherwise, you're headed toward a dead end
>>> IMO, as from your own admission of HTML imposed limitations,
>>> and I don't need to go down that path. You can use a
>>> patchwork of components and try keeping things together for
>>> a while, but eventually you'll long for the real thing;
>>> better be ready.
>>>
>>> As for WebGL, well it is what it is. That child may grow-up
>>> too someday. I am not asking to throw out the baby with the
>>> bath water. But, please, ensure that proper research is
>>> being done, as X3D is the elderly to look up to, and respect
>>> it deserves. I expect it to remain so for quite a
>>> foreseeable future. Thanks for coming to this list so we
>>> have an opportunity to express our opinions before the XG.
>>> That is truly appreciated.
>>>
>>> I do not really have too many questions, probably more
>>> answers. Feel free to ask. You will always get help from
>>> this list. No, "things are not as easy as they sometimes
>>> seem to be", unless I'd hold a hologram card in my hand
>>> (hilarious or dead serious - take your pick). But, you
>>> obviously have much drive and are not likely to quit; your
>>> mind appears set on many things. All of this is only to be
>>> useful. So good luck. I hope the XG will learn X3D,
>>> experience it, and really think things through before going
>>> too far with anything. No one wants 3D to fall flat.
>>>
>>> Now we can discuss the lack of adoption for 3D in general,
>>> but I'm getting tired. That maybe for another day. Let me
>>> just say that I am not convinced you have the right solution
>>> to this problem, maybe a partial solution at best. Many have
>>> tried and history has lessons to teach us here.
>>>
>>> Cheers,
>>> Lauren
>>>
>>
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org 
> 