KDE 3.2 feature plan

[az at azweb.de]

Hi!

> > As I don't think I will be able to finish the plugin framework, I
think we
> > should focus on implementing missing POV-Ray objects, especially the
new
> > 3.5 objects.
> 
> This sounds particularly great! Will you implement only missing POV-Ray

> objects, or will you also implement features like a GUI for Photon
rays?

Hmm, I didn't look at the POV-Ray 3.5 documentation, so I have no idea
what new objects version 3.5 has.

You don't happen to have a list of new objects?

> Among these:
> 
> -The possibility to use litterals terms (or words) unstead of numbers
in
the 
> fields of the various objects, with an optional 'parameters setting
window' in 
> which all such declarations could be put; this way it could be easy to
start 
> playing with macros directly within kpovmodeler. Perhaps a few tags for
the if, 
> while etc and other loops could be intersting also for modeling complex
items 
> where duplication of shapes is required

I thought about that, too, but had bellyache, that memory consumption
would be too high, if expressions with constants could be used for every
object attribute.

> -The possibility to insert/delete control points with the mouse on any
existing 
> segment (or in prolongation of a new one) when creating curves for use
with 
> Lathe, SOR, Prisms, etc. (perhaps does this exist already? Have I
missed
it?) 
> This should help modelling efficiently with kpovmodeler

There should be a "join segments" or similar entry in the context menu
when editing curves. That's what you are looking for.

> -When using curves (i.e. cubic or quadratic) it should be fine if the 
> supplementary one or two points needed to complete mathematical
calculations 
> be added or suppressed automatically when changing the curves from
linear to 
> quadratic to cubic then back to linear... Default vector (or recalling
the last 
> vector tried before curve type change) should be easy to put up, I
think? It's 
> always a pain when trying to model a fork using prisms: I always start
with 
> linear curves, and then shift to quadratic or cubic according to the
result, 
> and often I try one system or another.

That's a valid point.
Luis: Please add this to the feature plan, too.

> -When many cameras are set, the possibilty to choose which camera
should
be 
> used for the rendering (currently, the last camera item is the one
always used, 
> if I'm not wrong).

Yes, I think povray uses the last one.
All objects have now a "export" flag. If it is not set, no POV-Ray code
will be generated. With that flag you can control which camera can be
exported.

> -The possibility to see objects in shaded mode through OpenGL
facilities
(I 
> know this is slightly more than minor change ;o) because it's often
hard
to set 
> a scene in wire-mode only... This a whole feature which should be in
the
TOP 
> list, according to a user's point of view

That's my favourite item in the jobs list on the homepage, together with
CSG evaluation, but i doubt i can finish this in time.
There is even a comment in the view structure documentation, that the
view
structure contains vertexes, lines, and later the faces of the object.

So if anybody is interested to add faces to the view structure of all
objects, just shout.

> -The possibility to specify a different gravity/center point (and it's 
> materialisation in the 3d window) to each objects instead of the
asolute
0 
> coordinate point (way more cool when trying to adjust the rotation
angles of an 
> object AFTER a relocation or a resizing...).

You can add any transformation in any order to an object. With the
correct
order you _can_ move the center point.

> -The possibility to select two (or more!) objects and to align them top
or 
> bottom, left right or center, move them along a vector until contact is

> achieved, etc.

Hmm, I think hard to implement for lathe or prisms or even height fields.

> -The possibility to turn any primitive/result of CSG in meshes with
triangular 
> faces (no backward possibility, I guess?) that could be tweaked,
extruded, 
> etc... Meshes modelling tools (along with SubSurfs) are still lacking
to
KPM, 
> and using only primitives or external softwares like jPatch could be
painful 
> and/or restrictive as KPM suffers not being a stand-alone software for
complex 
> projects... This should be added prior to (or along with) animation
facilities, 
> IMHO.

I think that's already in the TODO file.

Greetings, Andreas