<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I believe it's time to take that old discussion up again.<BR>
<BR>
The mess called SOG/SOP that we have get to know and love came out of a simple question:<BR>
<BR>
* How would we, as application providers, like our object model?<BR>
<BR>
Now, 'we' at that time was mostly me and Darren, so empirical data and peer input was rather scarce.<BR><BR>
Anyway, at that time, I was still an LSL coder, and one of the things I really hated with LSL was the object model - the notion that an object could change 'role' and thus, you always had to if-then around cases like, 'is this a single object', 'is it a linkset?', 'is it the root object', 'is it attached?' in your code - adn where stuff like 'position' always changed meaning depending on the context. That's what I call 'if-then' coding. And it's bad.<BR>
<BR>
So, when reviewing how scene content was organized, we thought <BR>
<BR>
"we really should have a hierarchihcal model internally, where objects do NOT change behaviour and property meaning. And that model should be rendered into protocol-specific representations at the endpoint, ie, in the clientview."<BR>
<BR>
I still think that having an object that represents the object in scene, as opposed to having ten scene objects magically linked on 'root' id is a good idea - especially when considering stuff like mesh-enabled objects, where 'child prims' simply does not apply.<BR>
<BR>
But this time, maybe we should get more discussion. I bid you all ventilate your ideas. And references to other 3D models, and suggestions incorporating how grid, region, scene, avatars, attachments, mesh objects and linksets can work togehter in a single, simple API paradigm are extra welcome.<BR> <BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR> <BR>Join the 3d web revolution : <A href="http://tribalnet.se/" target=_blank>http://tribalnet.se/</A><BR><BR><BR></body>
</html>