[fluxus] Object Loader

[Christian Sandor]

Hi!

On Jan 2, 2007, at 8:50 PM, Dave Griffiths wrote:
>> About 3): I have added code as you suggested to that example
>> What I have added:
>> (define li (obj-load "meshes/bunny-1500.obj"))
>> then, I have changed the line:
>>          (let ((ob (build-cube)))
>> to:
>>          (let ((ob (obj-make li)))
>> Is this a good solution?
>
> yes - the list that obj-load returns is the vertex data in a form that
> easily translates to pdata setting, so it's sort of an intermediate
> format.
> it's still going to be slow at rendering as each bunny has to transfer
> it's pdata to the graphics card - it's also going to use up memory  
> as each
> one has it's own copy.
> a potential (build-instance) would accelerate all this by making sure
> there is only one copy, which could be managed better and only sent  
> to the
> card once per frame. pdata modifications to one bunny would affect all
> simultaneously, much like (draw-instance).
I understand. I would be very interested to use this potential build- 
instance :-)

>> About 2)
>> ....
>>
> (obj-load) should be improved to store a list of currently loaded data
> mapped to filenames, and then this would happen for you - much like it
> does for textures.
This sounds like a clean solution.

>> You wrote:
>>> It might also be a
>>> fix for the absurd load times to save out the list created by obj-
>>> load,
>> What did you mean by "save out"?
> something like ...
I have tested your suggestion. It brings down the loading time of my  
bigger model
from 70 seconds to 35 seconds. Not so bad! But, compared to the 0.5  
seconds
that glm.c needs .... :-)
Maybe incorporating glm.c into fluxus could be the easiest solution?

>> PS
>> As you have guessed correctly, I was about to ask you about using the
>> OPCODE part of ODE in fluxus ;-) ...
> I was just going to implement the ode trimesh - probably allowing  
> you to
> specify a different physics mesh from the renderable one, something  
> like:
> (active-trimesh primitive collision-mesh-primitive)
This sounds good!

> I haven't looked much into it yet, but am I right in thinking  
> opcode is
> the collision detection part of ode?
Opcode does collision of trimeshes in ODE (it can be enabled in ODE's  
config/user-settings).
It's a pretty efficient and free collision detection library.
Only downside is the lousy documentation.

> Would you want a lower level binding
> to that in fluxus?
> I can imagine it would be handy to use it to do fast
> intersections of things etc.

I think that
(active-trimesh primitive collision-mesh-primitive)
sounds almost sufficient to me.
If I remember correctly, opcode can return the list of triangles that  
are intersecting.
So another function for getting that list might be good.

Cheers!
	Chris