[sldev] Optimus Prim vs. Megatrim: "The Big Prim Problem"

[Dzonatas]

Argent Stonecutter wrote:
> On 17-Oct-2007, at 13:31, Dzonatas wrote:
>> Argent Stonecutter wrote:
>>> Just thinking of the obvious ways this could break makes me want to 
>>> run screaming.
>>
>> After you run wild and scream away, just list them.
>
> Just ask yourself why linksets aren't already handled the way you 
> suggest. They could be.

1) I can't read your mind for the exact reasons you are screaming (or 
want to scream). Please communicate them.
2) What you actually asked for me to do is to find problems with the 
currently implemented system, but we need to approach this in a more 
architectural way.  (Maintenance concerns, cost, use cases, etc)
3) My post is more comparable to a skeletal system rather than linksets. 
Each bone of the skeletal system would be an individual linkset. All 
related joints would be a individual linkset. Put those together and we 
have the basics of a skeletal system. However, in the current 
implementation with Havok1, we have linksets with unrelated joints and 
no bones. There are, however, vertex objects with related joints 
(avatars). The skeletal system viewpoint is way too early to implement, 
but that doesn't mean we can't design for it and make the more immediate 
implementation interoperable with potential future implementations.
4) We should not limit the architectural design to the current 
implementation (See 1 and 2 again).


>
>> For example, look at sculpties. The sculpt map is exposed.
>
> That was an optimization in programmer time.
>
> It's also not what you're talking about here, it's not an inner 
> attribute of prims that was exposed to allow optimization, it's a new 
> prim type that's exposed in a particular way because it was easy to do.

Actually, it could be done with the current implementation with minimal 
changes. I'll keep that detail private and work with a more potentially 
approved method.


> Also, it would have been better to accept an existing standard mesh or 
> nurb format, rather than a texture map. Making it a texture map has 
> required the development of tools that wouldn't have been necessary.

I think one your concerns is to use a standard mesh or nurb format. The 
current implementation uses a slightly optimized implementation of the 
standard, so your real concern is to have access to the source of the 
optimized vertex object?


>
> No, sculpties are hardly a good example.
>
> The point is that they were simple to implement, and they solved a 
> simple problem in a way that isn't too bad. What you're talking about 
> is complex and creates more problems than it solves.
>
> I'm still not sure it actually solves ANY problems.

See #2 again. I also noticed you avoided the comparable points from the 
SHARE case being exemplified.

-- 
Power to Change the Void