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

[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.
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.
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.

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.
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