[fluxus] Object Loader

[Dave Griffiths]

> Hi Dave!
> Thanks for the fast answer!
> I understand that fluxus is mainly intended for procedural modelling.
> However, combining procedural and conventional models seems like a
> nice thing :-)
>
> On Jan 2, 2007, at 10:06 AM, dave wrote:
>> On Mon, 2007-01-01 at 20:45 +0900, Christian Sandor wrote:
>>> 1) Speed
>> I think the obj-loader is probably quite easily improved
> ok! I will look into the model loader's code when I find time!
>
>>> 2) Caching of Loaded Models
>> You can do this with the current code, as you can call obj-load
>> once and
>> use the returned list in multiple calls to obj-make. It might also
>> be a
>> fix for the absurd load times to save out the list created by obj-
>> load,
>> as loading them in would not require any further processing.
>>> 3) Reusing pdata
>>> I do not know what to do: consider example/17-physics1.scm
>> no - it needs a build-instance! consider it todo'ed.
>
> funny thing: we seem to have a misunderstanding :-)
> actually, the first part of your answer to question 2) is solving my
> problem from 3).
> However, I am still unclear about question 2)
>
> About 3): I have added code as you suggested to that example. Now, I
> can see hundreds of
> bunnies flying on my screen :-)
> (quite slow though...)
> 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).

> About 2)
> The beauty of fluxes is that you can make a tweak to your program,
> then press F5, then see the changes immediately. However, with the
> currently slow obj-load code, it is more like... press F5... wait 1
> second....
> see the change. So my question 2) was asking: how can I get rid of
> the 1 second waiting time?
> More abstractly said: it boils down to saving state (=the loaded
> model) between several runs
> of a script.
>
> I have found a hack for achieving this (is there a better way?):
> I have put in my ~./fluxus.scm:
> (load "<full-path>/scm/objimport.scm")
> (define bunny-list (obj-load "<full-path>/meshes/bunny-1500.obj"))
>
> In my code, I write:
> (let ((ob1 (obj-make bunny-list)))
> Now, the object is loaded exactly once! No matter, how often I press F5.

that's a good workaround for the moment, and that's what the .fluxus.scm
is for. you are absolutely correct in saying what is needed is caching.
(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.

> 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 (code not tested :)

; load and process the .obj file
(define bunny-list (obj-load "<full-path>/meshes/bunny-1500.obj"))

; save the intermediate list
(let ((outfile (open-output-file "bunny-list.scm")))
(write bunny-list outfile)
(close-output-port outfile))

then once we have a bunny-list.scm, in your main script (or .fluxus.scm):

; load the intermediate list
(let ((infile (open-input-file "bunny-list.scm")))
(define bunny-list (read infile))
(close-input-port infile))

and use it as normal - this should mean that in the case of huge meshes
you are not needing to wait 45 seconds to start fluxus as it loads the
mesh in your .fluxus.scm

> PS
> As you have guessed correctly, I was about to ask you about using the
> OPCODE part of ODE in fluxus ;-)
> This should be awesome! (ODE's test_moving_trimesh.exe looks quite
> impressive)
> But, I understand: 0.12 has a much higher priority!

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)

I haven't looked much into it yet, but am I right in thinking opcode is
the collision detection part of ode? 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.

cheers,

dave