Graphical Views, and things.

[CARVALHO Luis Passos]

> -----Original Message-----
> From: Leon Pennington [mailto:leonscape at blueyonder.co.uk]
> Sent: sexta-feira, 4 de Junho de 2004 2:26
> To: KPovDevel
> Subject: Graphical Views, and things.
> 
> 2. Graphical Views. I started trying to work with the brep library,
Then
> started trying to implement something similar just with KPM, and have
been
> switching back and worth using different techniques. Its fun to do and
> experiment with, but not very productive so far. I'm back with brep at
the
> moment, just the C++ implementation has minimum CSG code ( So I'm
working
> with the C version ), also it adds another dependency we might not
want.
> 

The dependency is, in my opinion, a bad thing if you can implement the
code easily in KPovModeler. If not, then I don't think you should worry
that much
about the extra dependency. We'll have to add a check for it in
autoconf, though.

> 
> 4. Functions, been working with a way to interpret the functions, so
we
> can
> display the objects that need them by necessity ( and the moment just
> Landscapes, since I already have a way to display them. ) Its hard as
its
> means writing code to calculate patterns, I get something similar, but
not
> always Identical. The positive upshot of this is...
> 

Drooool. I hope you manage to achieve this. Won't it be painfully slow
though?

> 5. We could also you it as a way to display patterns as you change
> variables,
> so you can get a good Idea what each pattern would look like. ( I'd
find
> it
> useful anyway. )

We could have a special pattern preview just like we have a texture
preview. Press the button and a special scene is generated to render the
pattern.

> 
> Something that did occur to me for in display texturing ( for the
> graphical
> polygons )is using Pov to calculate them off-screen, and then pasting
the
> resultant image as an OpenGL texture, it wouldn't be completely
accurate,
> bit
> it would give you an idea how things are looking. It could get very
slow
> though.
> 

This may not be a good idea. It would be slow, plus how would you find
the right camera position to match the scale of the preview? I think it
would be better to allow rendering on top of a view instead of the
render view manager. That way we would generate an image that is
160x100, maybe 200x100. Less pixels -> less time.

Or we could do what povray does with quick_color. Just define a color
for a texture and use it when painting the faces of the object. That
would work as a preview, Helping to distinguish the objects. For the
scene compositing it should be enough, don't you think?

Anyway, great news. It's always nice to hear what our co-developers have
been doing.

This reminds me, I don't know if you've been checking on the cvs, but
the dcop interface already allows us to do some fun stuff. You can
already change most properties through dcop methods except:
	changing object links doesn't work right now
	In lists of values like pattern types, you'll have to know the
property integer values instead of names, which might be a pain, but I'm
working on it. 

Developing a program to move several objects one unit to the right is
possible already. I'll provide a few example scripts in the weeks to
come. In the object library front, it is missing search, and handling
external files, as for the rest, it's pretty much done and for the most
part stable. (at last!). Usability wise, I'd like to have your input if
you can spare the time.

Library creation is done in the Kpovmodeler Settings Dialog.
Object creation is done in the following steps:
	Open the library view
	Create a new object
	Change it's name, description and keywords
	Drag the objects into the scene file below
	Drag a picture over the "set preview" of the object.

Regards,
Luis