Re: [K-3D dev] K-3D future

[bondpaper]

Romain Behar wrote:
>  Well, all comments show that K-3D still has its place
> as a modeler on the Free Software scene.

3D, in my opinion, is one of those areas for which there will be no 
'perfect' solution, just different ways of dealing with it. Blender has 
its way of doing this, and I'm sure that that time it was initially put 
into service, it met some very real needs, albeit with a very limited 
audience.

One of things I *still* find impressive is the way that NaN built and 
maintained the Blender community. If an objective of the k3d project is 
to build a community of interested users, it might be of value to look 
at NaN's m.o. as a model. Wings3D is also experiencing some success in 
this area. The one thing that I think sets these community-oriented 
efforts apart is that they have community facilities: a dedicated web 
site with galleries, discussion areas, news, etc. The discussion areas, 
galleries, a mechanism for highlighting exceptional work from users, and 
regular participation on the part of the developer(s) are probably the 
most important of these.

>  To answer questions that were left unanswered in the
> past few weeks (I apologize for not posting as often
> as I would; be assured that you don't talk to
> yourself!), I'd say:
>  - `make check` does fail, this is not a feature :)
> the tests haven't been maintained for months

Ok - I thought there might be some connection between the failure of 
these and the frequent crashes.

>  - there are critical bugs with materials due to
> unfinished changes in shaders handling

I've been looking at various ways to generate documentation that 
generate a cross reference for the K3D code. Does such documentation exist?

>  - import/export function for Blender will be of
> importance when the format specification is released
> (POV 3.5 export has been on my mind for a while)

Blender can already export to VRML (1.0) and dxf (I'm not convinced that 
either of these are 100% reliable), and there might be python scripts 
that allow other formats as well. Blender doesn't have a format 
specification per se - from what I understand, a Blender file is 
essentially a memory dump. Both changing the file format to one that is 
more accessible (a text-based ML of some kind) or writing an API have 
been suggested, but I have no idea where this will be headed.

>  - an OS X port of K-3D will depend on developers
> doing the compilation, whether it's possible depends
> on the GTK availability on this platform


>  - sorry for other unanswered questions, feel free to
> post to the mailing-list
>
>  K-3D is currently built on GTK 1.2 based library
> sdpGtk (bundled with K-3D). The first goal is to
> switch to GTK 2.0; there are several ways to do it
> (using different libraries). The first and obvious
> way, is to port sdpGtk to GTK 2. The second one is to
> port sdpGtk to GTKMM 2.0, which is the official C++
> wrapper around GTK 2; this is the most difficult one,
> since it involves quite a lot engineering if we want
> to keep the dynamic XML-defined GUI, � la
> libglade. The third one is to rewrite the GUI part
> using GTKMM 2.0 and libglademm (IMHO, this is by far
> the worst one since it yields lots of library
> dependencies: GTK 2, GTKMM 2, libglade, libglademm,
> etc). The last one (and my favorite) gets rid of
> sdpGtk and the dynamic GUI to make a GTKML-free
> application based on GTKMM 2.

I've been studying GTKMM 2. I've also been looking at GLOW, which is an 
openGL-based toolkit. OpenGL has the advantage that it's very portable.
>  Another matter is splitting completely the 3D engine
> from the GUI (P. Christeas), to have a commandline
> application creating or modifying 3D scenes using
> scripts. This might be useful to make automatically
> generated animations, but I wonder how many people
> would need such product or whether this already
> exists. Some changes went toward separating tool
> algorithms from the tools themselves, since the same
> modifiers works for the tool and its animated
> counterpart. A stand-alone engine might be a good
> thing.

It is my feeling that the more you separate the engine is from the 
actual interface, the more options you have in terms of being able to 
interact with it.


Regards,
Tom
>  Cheers,
>
>   Romain
>
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
>
>
> _______________________________________________
> K3D-dev mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/k3d-dev