[X3D-Public] multiuser mode (newbie question)

Chris Thorne dragonmagi at gmail.com
Tue May 4 22:15:01 PDT 2010


On 5 May 2010 12:07, Dave A <dave at realmofconcepts.com> wrote:

>  pyth7 at verizon.net wrote:
>
> Seems David A on this thread disagrees with you:
>
> I'll be the judge of that ;-)
>
> I agree that X3D should be much easier to author. It is not. Who was it
> that said you don't even
> need to be a programmer? Yeah, only if your content is brain-dead (not
> 'horrible' just not
> a 'smart object' model). Otherwise, heck yeah you need to be a programmer,
> and understand protos
> and all that.
>
> The X3D spec was written by and for player implementors, not authors. Good
> docs and tools are
> few. It's a real shame that Vivaty Studio is now in limbo, as it was the
> only tool really aimed
> at authors (that is, artists, not so much geeks). There are a few other
> tools out there, for geeks.
> Or you can write your own. Not a way to run an airline!
>
> What is needed is a good open-source tool like Vivaty Studio. I know about
> Blender, it is far and
> away too overblown to be very useful for X3D but bless its heart.
>
> And I bless efforts to make a more semantic type of 3d. I came at this from
> game authoring tools
> where you could author something to 'spin' (with a speed and axis, not a
> bunch of key frames)
> or that something 'moves when bumped into' and so forth. This is a
> higher-level description which
> can be down-converted to X3D, very hard to go the other way. Tools should
> make it very simple
> for the non-programming artist, and produce the underlying code/structures
> as needed (this is what
> my Unreal converter does, btw).  Specifying things semantically is far more
> portable, if that's the
> goal.
>
> My point on the MU protocol, to get back to the original thread, was that,
> if any protocols could
> be used (thus spawning a 'protocol war'), then some mechanism for a 'user
> defined' protocol
>
that was part of the proposed network sensor specification - it was called
an "application protocol"
which rides on top of the http/udp or whatever is being used.

Butr if I get your point: some basic protocol (that uses this method/API)
should have been mandated.
I agree.

should have been mandated (and an open one be initiated), or short of that,
> a very basic
> common-tongue protocol which might be over-ridden by any particular
> browser. Thus, they
> could at least all speak to each other, but would speak best (more
> efficiently) if speaking to their
> own kind. Not certify as compliant if they could not at least do that much.
>
agreed,

chris

>
> Dave A.
>
> pyth7 at verizon.net wrote:
>
> Seems David A on this thread disagrees with you:
>
> May 3, 2010 04:42:15 PM, dave at realmofconcepts.com wrote:
>
> Seems like a 'user defined' protocol should have been a required option,
> and
> a public version spec'ed out for anyone to implement.
>
> But I can see why no commercial player vendor would implement such, they
> need to increase their user-base, you do that by requiring your player.
>
> [Russ Kinter]: Moreover, even if what you and Chris say happens, If I were
> someone who paid for a server using the propietary protocol (and I think I
> know of two) and suddenly the latest version of the client switched to the
> open-source protocol I'd be pissed to put it mildly and either (depending on
> my budget)
>  1. Can it entirely.
>  2. Move to another format.
>
>
> May 4, 2010 06:00:31 PM, cbullard at hiwaay.net wrote:
>
>   “To my thinking: the same motivation one would have to support openGL :
> increased portability and interoperability makes business sense to me.“
>
>
>
> Mine too.  Portability of content is what I want.   As the artist, I don’t
> WANT to pick the radios.
>
>
>
> Art production requires lots of time in.  For the time in to pay out,
> content has to be resilient to shocks from the browser.  That makes it hard
> to host and rehost anything but video.   Some really easy to apply interface
> widgets can greatly improve productivity but are costly to experiment with
> on the host given the distribution of the host.   Software kudzu.    One
> response is to identify and reward the strengths of the software instead of
> working to perfect the deficits, in this case, take advantage of X3D’s
> relative isolation and agree quickly to build widgets that DO reduce the
> authoring load and are sharable among the local software ecosystem.
>
>
>
> VRML/X3D browser vendors should be collapsing the space for ease of
> authorship * maintenance, or roughly, how much time can be spent making new
> assets vs maintaining viable stock resources.
>
>
>
> Ultimately content domains like biological domains cohere in the face of
> novelty through practice, memory and feedback.   A framework of response
> domains maps the services to the organizations that perform them in response
> to the panarchies that authorize them in response to the event/incident
> type.  That is the key to resilience.
>
>
>
> len
>
>
>
>
>
> -----Original Message-----
> *From:* x3d-public-bounces at web3d.org [mailto:x3d-public-bounces at web3d.org<x3d-public-bounces at web3d.org>]
> *On Behalf Of *Chris Thorne
> *Sent:* Monday, May 03, 2010 12:22 AM
> *To:* Russ Kinter
> *Cc:* X3D Graphics public mailing list
> *Subject:* Re: [X3D-Public] multiuser mode (newbie question)
>
>
>
>
>
> On 3 May 2010 13:37, Russ Kinter <pyth7 at verizon.net> wrote:
>
>
>
>
>   ------------------------------
>
> *From:* Chris Thorne [mailto:dragonmagi at gmail.com]
> *Sent:* Sunday, May 02, 2010 8:35 PM
> *To:* Christoph Valentin
> *Cc:* Russ Kinter; x3d-public at web3d.org
>
>
> *Subject:* Re: [X3D-Public] multiuser mode (newbie question)
>
> There appeared to be little will among the Browser vendors to collectively
> agree on and work on a standardised sensor node and protocol. It may also be
> that my expectations for real progress to an agreed standard in a 2 year
> time frame was unrealistic. Anyway, status quo seems a little better but
> nowhere near [my] original target, and I have moved on.
>
>
>
> *[Russ Kinter] But at the end of the day what remains of the VRML/X3D
> community now has an open-source Node standard that really isn’t
> open-source.*
>
> It is true there are no open source implementations of the proposed
> connection and network sensor nodes. but the nodes are not part of the
> standard as you seem to suggest.
>
>
>
>    *Do you really believe that the two biggest and strongest players
> BSContact and Octaga with their own protocols are going play nice and help
> establish one protocol in the future?*
>
>  I had thought it was to everyones advantage, including that of the
> Browser vendors..
>
>    *What possible motivation would they have for doing so?*
>
>  To my thinking: the same motivation one would have to support openGL :
> increased portability and interoperability makes business sense to me.
>
>    *Maybe it is a way to force customers who use their MU servers to buy
> the new version, because the latest versions of the clients won’t handle the
> old protocol?*
>
>  yes - that is a kind of vendor lockin than many companies go for. That is
> their business decision and I respect that, tho I don't particularly like
> it.
>
>    *Now that’s a sure way to gain and keep brand/format loyalty.*
>
>  :)
>
>    **
>
> **
>
>
>
>
> --
> http://www.vrshed.com
> There be greater truth at the centre: http://www.floatingorigin.com
>
>  No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.814 / Virus Database: 271.1.1/2851 - Release Date: 05/03/1001:27:00
>
> ------------------------------
>
> _______________________________________________
> X3D-Public mailing listX3D-Public at web3d.orghttp://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
>
>


-- 
http://www.vrshed.com
There be greater truth at the centre: http://www.floatingorigin.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20100505/05734f29/attachment-0001.html>


More information about the X3D-Public mailing list