Several (still) unresolved issues

Dave Durbin ([email protected])
Sun, 11 Jun 95 02:27:57 EDT


I'm working on the assumption that noone has responded to my previous posts because either :
a) Ultisnail didn't mail them OR
b) They were so garbled that noone had the patience to read them

So, using the *excellent* PM Mail, let's try again :)

1) QvLib 1.0 "Gold" code Including Text nodes et al.
Is this likely to be posted anytime soon? Is anyone working on it? Would any like me to volunteer ?

2) QvLib OS/2 and DOS/Windows ports
Is anyone interested in these ? Where should I post 'em ?

3) CSG modelling
Once we come to implement physical dynamics of worlds we are going to have to take account of things like mass and material composition. Conventional surface modelling simply cannot deal with this. The issue of material composition could be handled by extensions to the existing material node to incorporate properties such as density, elasticity etc. but this still will not help with the actual objects themselves.
CSG (Constructive Solid Geometry) allows us to define objects which actually have real volumes (and therefore computable masses) rather than merely surfaces. It also allows for logical intersections of objects (AND, OR, NOT etc.) and dynamic transformations (eg squashing , slicing etc.) which someone has already suggested as good and useful tools.
I propose that we need to consider implementing CSG modellling in release 1.1, certainly before we consider dunamics.

4) Messaging
Maybe I'm being a little preemptive here but for worlds to be dynamic we need to implement ways in which objects can change themselves and their relationships to other objects over time. This would seem (to me) to be best implemented using some kind of messaging interface between objects. I would envisage these being written in some appropriate scripting language (possibly Java) and stored in the .WRL file containing the object itself.
Now the tricky part. It seems likely that there will be several core "methods" for each object created (such as DROP, SQUASH, EXPLODE, SHATTER, ACCELERATE etc.) In order to avoid confusion I believe that we should define :

a) A core of these basic methods which must be implemented for all objects.
Consider the case of a world in which my objects need to interact with my clients objects. If we do not have a common minimal subset of methods how can we hope to interact?

b) A way of declaring this core (and any additional methods) within an object definition.

Any and all commenst are appreciated.

Regards,
Dave

+-----------------------+---------------------------+
� Dave Durbin � [email protected]
� Visual Systems Solutions � [email protected]
� Who ? � [email protected]
+-----------------------+----------------------------+