Preview of objects

[olivier at linuxgraphic.org]

Hi all,

thanks to Luis and Leon who answered me very quickly. I'll give only an answer 
to Leon because I think that my answers are valid for both Luis and Leon, if 
I'm wrong feel free to shout after me ;o)

>I think the real hard part is parsing the functions, and understanding them.
>The Current parser for importing Povray files is over 7000 lines not
>including the scanner and tokens, and thats with a very strict set of
>keywords and a strict structure.

It seems that macros included in the povray package are consistent the way they 
work: a name followed by a set of properties. This is why I think that they 
could be directly incorporated into kpm (under the true primitives they are 
degenerated from...) and there properties tweaked through the properties view, 
instead than calling theses objects from Luis' object library/browser.

>When their in relation to an object say like an Isosurface, we've got a
>reference to work from. When you start using them to create objects, it gets
>even harder as the functions are designed for a solid Object, and not
>wire-frames. For instance how would you represent the clouds object from the
>Povray Benchmark scene in a wire-frame? Its basically a pixel representation.

These macros are consistent and all official, there should be no more trouble 
adding them to the list than adding any new object from 3.5. What could be done 
is to access these sub-items through icons (with a little arrow added on the 
original icon indicating that you can develop a view with more icons) and/or 
through a field (in the properties view of the original primitive) like the one 
that let you choose which kind of Pattern you want to pick and/or through the 
menus (one more level of detail down).

Please note that I'm not (yet!) talking about macros that generate meshes or 
patches through raw code and 'if' loops (or that kinda sort). If I understand 
well, kpm should have to parse the file and generate the according mesh before 
showing the result on the 3d view. I guess this can take up to a long time and 
that building the wire frame from what has been parsed can take time also. But 
you could do this only when truly needed through the use of a 'parse' button of 
some sort? It could be a good idea, too...

>Generating Heightfields from functions would be easier (its something I've
>been thinking about.) Maybe we need a part to deal with functions? So we can
>tap into it for Heightfields, Isosurfaces, etc.. I think Andreas has been
>working on this anyway, (Although I could be way out here.)

i'm not sure to understand what you're talking about... :o(

>Previews? Well if its done heightfields and Isosurfaces wouldn't need
>previews as you could see them in the views, But for Objects I could
>understand that, but size would be difficult to control with the preview
>window. Also theirs the fact that most functions don't mean much on their
>own.

For isosurfaces, you could need some ray-traced previsualisation of some sort ; 
sure, it's not mandatory, but it could be helpful until a gouraud shading is 
available in the 3d view... Figuring a complex shape from a wireframe view can 
be a real difficulty when you need to fine adjust objects to others, and having 
a quickly raytraced thumbnail from it could be helpful.


Well, I'm off now, I hope I'm not boring you with all these fuzzy ideas...

Cheers,
OlivS