[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kpovmodeler-devel
Subject:    Re: Graphical Views, and things.
From:       Andreas Zehender <zehender () kde ! org>
Date:       2004-06-04 20:06:00
Message-ID: 200406042206.00017.zehender () kde ! org
[Download RAW message or body]

Hi all!

On Friday, 04. June 2004 20:36, CARVALHO Luis Passos wrote:
> 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.

Can't we in include the brep library or just some algorithms in kpovmodeler? I 
don't think the brep library is widely used and installed ;)

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

That's my fear, too.

> > 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.

Yes, and imagine views with fisheye projections...

> 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?

*GGG*
Quick colors are already used as colors for wire frames.

> 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.

Wow, cool.
Please don't forget to add your features to the official feature list for KDE 
3.3
And keep head stable or hide experimental features. See
http://developer.kde.org/development-versions/kde-3.3-release-plan.html
http://developer.kde.org/development-versions/kde-3.3-features.html

Greetings, Andreas
-- 
--------------------------------------------------
 Andreas Zehender
 Master of Computer Science, Dipl. Ing. (BA)
 http://www.azweb.de
 az@azweb.de | zehender@kde.org      
--------------------------------------------------

List archive and information: https://mail.kde.org/mailman/listinfo/kpovmodeler-devel
[prev in list] [next in list] [prev in thread] [next in thread]