Recent Forum Posts
From categories:
page 1123...next »
mpegv+req.jpg
Dear all — I participated in the first meeting of the forum.
You are invited to direct your energy toward this more official and structured work
on the same topic of standards.

Personally — I feel that the ISO process saves a lot of problems in the jump start of this complex topic.

See this full invite here:http://www.dryesha.com/2008/05/call-for-requirements-iso-mpeg-v-mpeg.html

Here's a brief:

My dear friend, J.H.A. (Jean) Gelissen from Philips continues to work on MPEG-V. This is the major official (read: global) work on establishing standards. Most of you are aware of my "push" for global standards (see Five dimensions of standards, and the metaverse1)

I fear that the virtual worlds industry, will end up like the gaming industry — small islands that stifle large scale innovation. In contrast, the internet model, with its defined stack, is a much better example to arrive at the full 3D3C real virtual world.

Outline

1 Communications

While every virtual world has developed in world methods of communications, the problem of establishing communications between a person in one virtual world with another person in a completely different virtual world has not been solved. Virtual worlds provide an environment for rich communications not previously available thru avatar animation. Virtual worlds also provide a common environment for mixed modes of communications such as text and voice in addition to the gestures and emotional indicators presented thru avatar animation. Virtual worlds also provide private or public communications to occur between individuals or groups. The problem here is how to extend this beyond the confines of a single virtual world.

1.1 IM

1.2 Voice

1.3 Animation

1.4 Media streaming

2 Policies

Each owner of the virtual world needs to be able to specify what and what can not be done in their world. In a large world this may be subdivided down to account holders. Policies determine the rules of engagement between avatars and their environment. While this may be determined completely from the server side, we need to look at what needs to be done from the client point of view as well. Do we tell the client what it can do and what it can't do or do we just ignore requests from the client that is not allowed.
Along with defining policies as a capability of virtual worlds, we should also look at basic rights for visiting avatars. When we move from world to world, we must retain rights to control our avatars. We can not allow impersonation or hijacking of our avatars. We must always be allowed to leave a virtual world.

2.1 Avatar rights

2.2 World policies

3 Global presence

The are of global presence covers areas that are independent of the virtual worlds and answers questions such as if my friend online and if so where? Global presence is a manner of finding contacts beyond IM, telephone network and virtual world presence. We want to be able to locate our friends and associates no matter what service or virtual world they are connected to (with their permission of course). A global presence system will allow a user to move from one system to another without entering login information again and again. When someone wishes to find someone online, the global presence system will connect them to the desired party no matter how or where they are connected.

3.1 Identity

The global presence system provides a central authority for identity of users. Pseudo - identities are allowed and protected as one moves from one virtual world to another. A users real identity is always protected as securely as possible.

3.2 Login

When a user enters a new virtual world, the global presence system logs them and identifies to the virtual world the avatar and pseudo - identity that is to be used.

3.3 Location

When a user wishes to contact someone, the global presence system figures out how to connect the two parties without revealing either one's location to the other.

4 Content

Content is the most significant aspect of interoperability between virtual worlds. The issues surrounding the moving of avatars and other content between virtual worlds is the most challenging and will require the most effort.
The first thing we must realize is that avatar content can come from anywhere on the web. Just as images and other forms of content are distributed across the web, we need a way to allow people to own their own content and save it where they wish. In order to do this we need to provide a method of locating content similar to the way URLs are used today.
The specification of 3D content and more abstract content such as agents or presence may require more than just URL to well defined class of object such as an image or html page. Context will be important in determining the proper content that is sent to the requesting party. Context will include such factor as user preferences, owner defined properties, viewer capabilities and environmental variable on a global scale. In the future what each person experiences as they browse the 3D web will be different based on their user profiles. These profiles will be generated with or without the users knowledge.
We need to look at what type of content we want to support as we move from one world to another. 3D content is a given of course, but there are more complex data types we need to consider. The avatar itself is much more than a 3D object. It is an animatable object. It is tied to communications channels. It is also scripted. A major focus needs to be placed on how to move avatars between worlds of which 3D objects is only a small part of the problem.

4.1 Context

4.2 Plugins

4.3 Translation

4.4 Scripting

4.5 Characteristics

4.5.1 Temporary

4.5.2 Transient

4.5.3 Dynamic

4.5.4 Static

4.6 URL

4.7 Access rights

Outline of areas of interest by NathanXNathanX, 15 Apr 2008 16:29

[quote]Interoperability between the backend servers of current virtual worlds providers will only make the walled garden bigger.[/quote]

Actually, if you can keep growing the walled garden until it includes all of the world, what's wrong with that? The walls will effectively go away.

[quote]Making existing virtual worlds interoperable is not the goal here.[/quote]

I would like to take strong opposition to this stance. Internet e-mail was made a really large phenomenon exactly because it started including Compuserve, AOL, Exchange, and other systems that started out as separate systems. Meanwhile, instant messaging had an "open standard" (or two, or three), but did NOT focus on making sure that the incumbent players talked to each other — and that ended up with the current balkanization that isn't going to go away.

Let's make sure we make virtual worlds like e-mail, not like IM.

Re: Scope of forum by jwattejwatte, 09 Apr 2008 21:15

My position

Interoperability between the backend servers of current virtual worlds providers will only make the walled garden bigger.
We must not constrain the evolution of the 3D web.
We should be looking at how we enable the evolution of the 3D web, not trying to solve the interoperability problem. Making existing virtual worlds interoperable is not the goal here. We did not integrate CompuServe, AOL and Prodigy to create the web. Instead we created HTML to allow anyone to create a web experience. I think we should be doing the same thing, enabling the 3D web not conglomeration Second Life, Active Worlds, There etc.
Currently each virtual world manages the content present in that world including avatars, objects, sounds, animations and scripts. As we move between one virtual world to another, we must allow content to come from anywhere.
Each virtual world developer must be able to define their policies without regard to the client. In other words, the client must be independent of virtual world policies.
If we want to enable the 3D web, we must create an open standard that allows for reuse of server code plus the divesture of common standard services.

Scope

Reuse of current standards
Let's not create competition among standards
Enablers, not solutions
Let's create a process for solving problems and not focus on solving them
Should not be limiting
We can't anticipate what will be created
Examples
URLs for locating content
OpenID for establishing identity
XML for descriptors
Virtual World policies
Each VW must be able to define its own policies
Transient, persistent and permanent content
Avatar abilities
Scripting
Content creation
Content and avatar formats
Like audio and video files, formats should not be defined. But a method of identifying formats should created.
When entering a VW, the appropriate content types will be loaded and rendered
Content can be converted from one format to another or be produced from a master content format such as Collada by a third party service

What should we do?

Create a way of locating content
So that content may be distributed across the network allowing users to be responsible for their own content
Create a way of specifying context for content
So that the appropriate content can be loaded and rendered at the client
Create a method of describing policies
So as to specify what can and cannot be done in a virtual world
Create a method of managing identity
So as to make the annoyance of login every time we move from one world to another lessened
Suggest that the client be as thin as possible and decoupled from the virtual world itself.
Virtual World balance between client and server. Online multi player games load more functionality to the client side to reduce server load. Lets discourage this as it makes the client tightly coupled to a particular virtual world (game).

Scope of forum by NathanXNathanX, 20 Mar 2008 19:47

trying to sort out file uploading to forum pages.

forum:thread/opengl_logo_test.jpg

Re: Test- First Post by Suzy DeffeyesSuzy Deffeyes, 20 Mar 2008 12:07

I would disagree with this statement: "moving a simulation from one RTI vendor to another requires significant engineering effort".
This either does not require anything more than compilation and linking with another RTI or does not require efforts at all (just change DLLs)

Alan, assuming your qeustions are for me and I'm not sure they are…

Scripting is really outside the domain of what I was focused on. For SL, it is only server side but as you point out, something like a windmill might be better on the client. My main focus was how to architect the geometry pipeline so that a particular format isn't built into the standard.

Stepping beyond the geometry question, for any geometric data on the server, you have to have some way to render it on the client. If you are animating the geometric data (i.e. via a client side script) some interface is needed to the "geometry format specific" renderer on the client.

At this point, you can't really say exactly what the interface to a "format specific geometry renderer" might be. You need an interface between the real renderer in the client and any "addin" renderers. If you have client side scripting, you may need another. You might also envision some server side interface for comunication back to the server. Or the renderer may be buried under other code (i.e. scripts may not even care about a "renderer", just the that object moves)

Exactly how these interfaces are implemented is yet another *huge* question!

Re: Object mesh interchange by burhopburhop, 11 Feb 2008 15:39

Feb 5, 2008 VWIF meeting

Attendees

Terri Ertlmeier

Chuck Powers

Mike Danielsen

Peter Haggar

Suzy Deffeyes

Mic Bowman

George Goodman

Paul Fahn

JP McCormick

Rick Knowles

Mark Lentczner

Jon Watte

Summary

The meeting was hosted by Motorola with Terri providing dial in and Mike taking notes. Mic provided an analysis of our positions on forum policy which was the focus of the meeting. Mic provided a document to all ahead of time for the discussion. This document, everyone should have but it is copied at the bottom just in case.

Three things we agree on

1) We want specifications and standards that are, to the best knowledge of all forum participants, free of IP encumbrances. Note, however, that we cannot guarantee that a specification is unencumbered because we do not know when a specification touches on IP owned by a company that does not participate in the forum (and at some point we probably need to think about how to address that situation).

2) We agree that any IP generated as part of the activities of forum are “owned” by all members of the forum. More likely it means that all members of the forum are granted RF licenses to all material that is generated, for example, during working group sessions, and wiki or forum posts.

3) In order to limit liability, activities in the forum should be explicitly scoped (at some level). The goal is not to encumber the standards & specifications, but to be “intentional” about handling IP.

Can we define a scope of activities that determine first set of work items that is sufficient for lawyers to agree on RF?

One of the things holding back approval of the alliance proposal is that the scope of alliance has not been specific in its definition. There are many views of what the scope should be, but Peter said that the scope is balanced between open ended and too tight because of the unknown. Others pointed out that overall forum charter can be broad, but the working group charter should be more focused. (I think we are all in agreement with this. If not please follow up.) But at this point no working groups have been defined. It is the fear of many participants that membership in the forums will require close monitoring of the WG's even if the forum participant is not a member of the WG.

Scope (1.8 of the Alliance proposal)

1.8 "Purpose" means the development, enhancement, and promotion of programming technologies and techniques,

implementation profiles, testing software or scenarios, development toolkits, runtimes and other relevant material to enable

interoperability between heterogeneous Virtual Worlds including the publication of Forum roadmaps, Specifications, testing

materials, and sample implementations that can be used to promote Virtual World interoperability technologies and techniques.

Can we define a scope of activities that determine first set of work items that is sufficient for lawyers to agree on RF.

Chuck replied that the devil is in the details but if we have sufficiently well defined scope, then members of the WG can agree to RF with withdrawal before WD draft.

The forum asked Mark if he would be willing to write a more specific scope than was provided in the proposal.

Can we agree on a structure that is low overhead but allows us to grow?

Chuck will look into various organizations in order to report back with some examples for us to look at.

How do we ensure that there are no IP encumbrances from members of the forum?

It was suggested that a WG participant will withdraw from the group if it wishes to protect IP before the working draft is released. This was met with general consensus.

Mic will draft a new proposal

Intel will host next weeks meeting.

Feb 5, 2008 VWIF meeting by NathanXNathanX, 07 Feb 2008 19:28

Couple of questions for you on this:

Are local animations supported(ie non networked) like a windmill. Looking at the diagram I expect it might be handled by the renderer on the client? Ie if the language supported a runtime then it would be run there?

Is it the scripting mechanism which provides this or do you have local interpolators?

How does a client piece of code(ie say a car) that wants to talk with the network do this? Ie say I want to display the current time and weather in an in-car display? Typically you'd use web service, ajax etc to get this data. Can an object have access to the web to display local information?

http://slurl.com/secondlife/Notha/194/82/21

I would like to offer my factory as a place to socialize in Second Life. All are welcome to visit the above location. We will not discuss politics; that can be saved for Tuesday meetings. This is not meant to be an endorsement of Second Life. It is just my personal land in SL that I am making available as a meeting place.

Factory

I have some alternate views on those same points:

1. If people could exclude IP, members would have to familiarize themselves with all of the excluded IP so that they could come up with specs that didn't read on it. People may also want to know what IP is excluded before joining the forum.

My vision is that IP exclusion is done very specifically, i e "claims X Y and Z from patent PPPP," and that the exclusion applies only to the specific proposal/standard. If some other proposal/standard comes out that reads on the same IP, you'd have to exclude that, too, if the IP was that important to you.

2. When a WG puts out a spec, there is the possibility that the IP owner will say that the spec reads on the excluded IP. The WG will likely say no, and a disagreement will ensue. This disagreement could be with or without merit, but would have to be resolved before the group could move forward on that particular specification. How this process is managed would have to be defined and agreed upon.

Excluding the IP means that the forum member says "I reserve the right to enforce these protections against members of the forum." If the WG really feels there is no infringement, the WG (in cooperation with the SC) can still release the standard, with the caveat that a court may find that an implementation of the standard might actually infringe on the IP, should the excluding member decide to pursue.

3. If IP were excluded, a WG could then possibly be in the position of coming up with a substandard way to do something as the excluded IP might contain a better, or the best way.

That being the whole point of IP for start-up companies. I believe that it is totally possible to come up with many relevant, useful and enabling interoperability standards for virtual worlds, while still letting those doing the work have IP on implementation details, and maybe even on "more efficient" ways of doing things. Purposefully excluding those who actually do work in this area and have some core IP they are not prepared to give up seems to be bad for the forum.

5. The addition of an exclusionary procedure for IP adds considerably to the complexity of the organization and the administrative costs for participants.

We have to weigh the openness for organizations to join and participate (no matter what their particular IP situation) against the costs of participating in the forum. I don't understand how an IP agreement that says "you have to give up any IP to anything that anyone gets into a standard from the forum" would be viewed as less of a bar to entering? To my mind, that's a much higher bar to clear.

This is a copy of Peter Haggar's comments on the following discussion of these points:

I posted the meeting minutes on the wiki here: http://vwinterop.wikidot.com/jan222008meeting

I wanted to raise a couple of points regarding excluding IP from either the Forum or a particular WG which is embodied in position number 2 and 3 in the minutes.

  1. If people could exclude IP, members would have to familiarize themselves with all of the excluded IP so that they could come up with specs that didn't read on it. People may also want to know what IP is excluded before joining the forum.
  2. When a WG puts out a spec, there is the possibility that the IP owner will say that the spec reads on the excluded IP. The WG will likely say no, and a disagreement will ensue. This disagreement could be with or without merit, but would have to be resolved before the group could move forward on that particular specification. How this process is managed would have to be defined and agreed upon.
  3. If IP were excluded, a WG could then possibly be in the position of coming up with a substandard way to do something as the excluded IP might contain a better, or the best way.
  4. In a RAND model, people can work to get their stuff (or their friend's stuff) as part of the spec in order to generate royalties.
  5. The addition of an exclusionary procedure for IP adds considerably to the complexity of the organization and the administrative costs for participants.

Each of these points is contrary to the goals of the forum, which is a free and lightweight forum to develop RF specs to enable wide and unfettered industry adoption.

I think everyone needs to come to Tuesday's call with a firm stance on at least two things:

  1. Do you support RF or RAND specs as output of the forum?
  2. Do you require IP be excluded (at either the Forum or Working Group level)?

Let me know your thoughts, and/or we will continue the discussion on Tuesday's (1/29) call.

One link to take a look at is

http://wiki.secondlife.com/wiki/Geometry_Based_Architecture_View

While this is focused on some long term future Second Life, the general idea abstracts away the specific geometry formats. That is, it sets up a way of working so that any (most?) formats could be used.

This allows formats to compete within the standard rather than making a particular format a standard (kind of like how you can use HTML or PDF or Word as your document format in a browser).

Re: Object mesh interchange by burhopburhop, 24 Jan 2008 17:03

I too, come from an X3D bias, but sometimes familiarity breeds contempt :-)

In the VW system we are building we have made a conscious separation between assets and behavior, storing assets in X3D (because our Flux Player web plugin does a great job at rendering it) and dynamic behaviors in Javascript code and ancillary XML data (because a web browser does a much better job at those). As an aside, this separation will also allow us to deliver assets in COLLADA if we so choose in the near future— or OBJ or whatever. But X3D and COLLADA are the front runners and it's practically a coin-toss for us. We already ingest COLLADA into our Flux Studio tool and export X3D anyway.

But as Alan point out, we also have to be careful about what we are defining as "behaviors." I believe that predefined animations can be authored and stored in the DCC tools and preserved throughout the chain as part of the "mesh data," as jwatte calls it and that is far preferable to defining those in program code. i.e. I wouldn't want to animate key frames in a Javascript timer loop.

IMO the big win is in separating program logic from asset data and a good design should reflect that.

If some IP holders can't accept having to come up with a definitive answer in a limited amount of time, and some other implementors can't accept working with standards where the IP status is unclear, two fora could be started, one with RAND terms, and one with RF terms, and then they could compete in the open market. In my opinion, that would be a poor outcome, but unless IP holding Forum members can commit to a deadline after which IP is considered RF, I don't see how a truly open set of standards (a la the Web) can be developed by the Forum. I believe the main points to emphasize in Option 2 over Option 0 is the ability to selectively opt out of providing specific IP on an RF basis, without having to leave the Forum.

It seems I can't attach a Word document here, so I'll paste the entire thing in:

IPR Policy Discussion Summary and Analysis

During the phone conference on 1/15/2008, the tentative Virtual World Forum members discussed a number of different approaches to structuring the Intellectual Property Rights agreement. This document attempts to condense the main points made, and do an analysis of the proposals in the context of the goals of the Forum. The document is based on notes taken by Jon Watte, Forterra Systems, during the phone call, and may not perfectly capture all the points made. Please feel free to add anything you find missing to the Wiki, or send me e-mail as jwatte at the company forterrainc in the com domain.

Glossary:
IP: Intellectual Property (typically patent rights)
RAND: Reasonable And Non-Discriminatory terms
RF: Royalty Free
SC: Steering Committee
WG: Working Group

Conflicting perspectives/goals

There are multiple perspectives that the procedures and IPR policy needs to take into account. During the discussion, at least the following perspectives were identified:

IP holder’s perspective
Wants to be able to monetize crucial IP
Wants low risk of inadvertently losing that right
Wants low cost of participating in the Forum
Forum’s perspective
Wants to develop standards without extensive terms/cost discussions
Wants to include as many market actors as possible
Wants standards to be adopted
Individual implementer’s perspective
Wants standards adoption to be uncomplicated
Wants known costs of adhering to a standard
… only possible WRT Forum members, not others

The current agreement (call it “Option 0”) has two deficiencies that make it unpalatable to IP holders:
1) It forces any member to make any IP available on RF terms, even if that member was not part of the WG.
2) The only way to opt out is to totally leave the forum, which does not lead to good co-operation; this can be used to effectively force people out.

Additional assumptions:
- Any disclosure from an IP holder should cite specific patent language, and how it applies to the standard. This is to avoid IP holders making statements like “we’re sure we have something that might apply, so we’ll just make a blanket statement and sort it out later, if we feel like it.” The possibility of making such statements will likely be a hindrance to developing and adopting open standards.
- Any IP holder must have some mechanism of opting out of providing their IP on an RF basis, even if that IP holder is not member of the WG. Else some IP holders may never join the Forum to begin with.
- Non-RF, Non-RAND terms likely are equivalent to vetoing a standards proposal. I have a hard time seeing how a standard could be adopted with someone disclosing their intent to discriminate and/or not license.

We have discussed two alternative structures: RAND default, or RF default.

Option 1: RAND default

Description:
Member on working group who has IP related to the standard will disclose what that specific IP is and what the terms will be:
- RF
- RAND
- Non-RAND*
Once the WG proposal is voted by SC, there is a waiting period. Any Forum member with IP related to the standard can during this period disclose what that specific IP is and what the terms will be:
- RF
- RAND
- Non-RAND
Under this option, a Forum member not disclosing within the waiting period, implicitly commits themselves to making any IP related to the standard available on RAND terms.
After the expiry of the waiting period, the WG and/or SC decides on whether the standard should be issued with the disclosures made, or re-worked. It is likely that non-RAND terms would be a deal killer.

Analysis WRT goals:
IP holder: This appears acceptable by most IP holders. An IP holder who does not wish to spend effort during the waiting period can do nothing, and later collect RAND fees if some infringement is detected, so exposure to giving up IP unintentionally is limited.

Forum: There is great risk that WG meetings will devolve into companies trying to get their particular technology legislated in a standard, to turn it into a money-making proposition. This is expected to add time to the standardization process, and might preclude certain standards from being formed or optimally executed.

Implementer: “RAND” is a big unknown for an implementer. What is “reasonable” for one person might be an economic infeasibility for another. RAND also likely excludes any open source implementations, as you couldn’t use them without paying license fees. Perhaps worst, even if a standard is currently thought to be unencumbered, any member can at any point in the future decide to enforce IP that was not disclosed during the waiting period, on “RAND” terms.

Option 2: RF default

Description:
Member on working group who has IP related to the standard will disclose what that specific IP is and what the terms will be:
- RF
- RAND
- Non-RAND
The WG will generally choose to work around any RAND or Non-RAND terms to keep the standard RF. Only in circumstances where there is no alternative would an encumbered standard be considered.
Once the WG proposal is voted by SC, there is a waiting period. Any Forum member with IP related to the standard can during this period disclose what that specific IP is and what the terms will be:
- RF
- RAND
- Non-RAND
A Forum member not disclosing within the waiting period, implicitly commits themselves to making any IP related to the standard available on RF terms.
After the expiry of the waiting period, the WG and/or SC decides on whether the standard should be issued with the disclosures made, or re-worked. It is likely that non-RAND terms would be a deal killer.

Analysis WRT goals:
IP holder: An IP holder that is part of a WG will have time during development of the standards proposal to analyze whether the standard necessarily infringes on its IP, and disclose it during the WG. Any IP holding member will have time during a waiting period to analyze whether any IP applies. This waiting period is intended to be in the 30-45 day period (and likely should be specified in the IPR).
A member of the forum who cannot do a full analysis during the waiting period runs the risk of having to make their IP available on an RF basis to any implementer of the standard.

Forum: When there is a requirement for WG members to disclose IP in the WG, and the WG favors non-IP-protected standards, then jockeying for revenue will likely not be a factor in the standards process.

Implementer: An implementer will know, after the expiry of the waiting period, that no member of the Forum will enforce non-disclosed IP against implementers of the standard after the fact. Free and Open Source implementations are allowable.

Discussion

Balancing the goals of IP holders, versus the goals of creating standards that will see widespread acceptance, is as much art as science. The W3C prefers royalty-free standards, and it is probably safe to say that the web we have today probably wouldn’t be nearly as open or widespread had it been RAND based. A standards policy based on RAND (Option 1) is safe and risk free for large and small IP holders, but is less likely to generate good standards in a timely fashion, and those standards are less likely to see widespread adoption on par with the 2D web.

Option 0 (the original agreement) seems to go too far in the other direction, making it possible for competitors to force others out of the Forum by proposing a standard that mimics core IP of those parties, and the only way to object to such a standard under that agreement is to leave the Forum. Given that the Forum could develop a large set of standards in different areas (from large-scale integration architecture, through virtual goods commerce, unified presence down to details like avatar looks), such an all-or-nothing approach probably will foment too much dissent.

I believe Peter (Haggar) is right: you join a standards body to actually do real work in the area of the standard. Part of that is the expectation that you have to give a little to get a lot. Thus, a system where members by default give RF rights to IP, but have the possibility to veto those rights, seems to strike the right balance. I don’t see how such standards can reasonably be accomplished without having a set calendar deadline, after which a proposed standard can be assumed to be RF from the point of view of Forum members. Thus, I believe a waiting period, with a default of RF licensing if nothing is said, is the right trade-off. If, as an IP holder, a standard concerns something you really care about, you’re likely either on the WG (and thus have lots of advance warning), or you know enough about it that you can find the proper IP during the waiting period.

Thus, a member joining the Forum, under Option 2, commits to review published standards within a given deadline, and takes the risk that anything missed during that review period will not be enforceable against implementers of that standard (or at least other members of the Forum that implement that standard). Although some IP holders may find that this is an uncomfortable risk, I believe it’s a risk we have to take, to achieve the greater goals of an interoperable 3D internet.

Can you describe the systems that have split out dynamic object behavior. Do you just mean scripting languages that can access the object description?

I come from X3D bias so I'll state that up front.

What I've liked about VRML/X3D systems is the packaging of visuals and behaviors. Ie when I want a dynamic object I typically need to refer directly to things inside the object. Let's take a car for instance. Let's say I have 3 behaviors. Open doors, move steering wheel and display turn signals. In order to activate the first two you need to know when the user "touchs" the door handle and steering wheel. This is handled in X3D by a Sensor(touch or drag in this case). The sensor is a marker for "when the user interacts with this do something". The other way I have seen it done is more direct. Ie the scripter controls a pick ray and is told what intersected. I like X3D approach in this better because the script is attached directly to the operation. Its not off in some other picking area. The other side of this, display the turn signal. Again this operation is fairly tightly coupled to the graphics picked. Do you swap textures, change emissive color, change a shader param? You can abstract the action, but its still tightly coupled to the choosen geometry.

Can you point me at behavior systems that you like better? I'm especially interested in declarative systems that other tools can make sense of. Just a wad of code for all the behavior system is very hard to read into many tools.

page 1123...next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License