atom feed2 messages in org.kde.kpovmodeler-develKDE 3, current status of textures, de...
FromSent OnAttachments
CARVALHO Luis PassosSep 5, 2001 12:20 pm 
Andreas ZehenderSep 6, 2001 11:10 am 
Subject:KDE 3, current status of textures, declares, etc...
From:CARVALHO Luis Passos (
Date:Sep 5, 2001 12:20:29 pm

Hello everyone!

As far as KDE3 goes I totally agree. Let's focus on getting a version out for KDE2 and then port it to KDE3.

Status of development ~~~~~~~~~~~~~~~~~~~~~ Bringing you all up to date on what's happening in the textures development, currently finish is fully implemented and map patterns are working at 50% completeness. I'm checking code generation and the canInsert() methods for correctness. Map Modifiers like warp are not working yet, they are next on the line before I submit a patch to Andreas. ETA on the patch is around the weekend of September, 22nd-23rd. Then, as soon as the patch is applied to the repository, you can add some shine to your test scenes. No support has been made for normals yet. After I submit Map Patterns for Textures, Colors and Pigments I'll be working on that.

PMDeclare and it's subclasses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On the course of developing textures I've found a lot of places where a class inherited of PMDeclare has to be developed (PMTextureDeclare, PMObjectDeclare, PMColorMapDeclare, PMSkyDeclare,... well, it goes on and on and on. Each of these objects is alike, changing only on canInsert(), description() and isA(). It seems to me a great waste of time, developing all these diferent objects, actions, menu entries, tool bar icons, etc for an object that is basically the same everywhere. So my idea is to just have one PMDeclare, with one action, icon, menu entry, etc, which implements "#declare <ident> =". At first, it's type is PMTUnknownDeclare, and accepts any child that. As soon as a child is inserted in the tree, PMDeclare::type() will return the current PMTObjectDeclare or PMTextureDeclare or whatever. All the PM*Declare classes existing now would disappear. The icon would be put next to translate, rotate, scale, comment and other generic use objects in the toolbars. What do you think?

Random Thoughts ~~~~~~~~~~~~~~~ The following are just some random thoughts on things that I think we must tackle sooner or later.You can just ignore them or, if you feel like it comment on these ideas: - One thing that has me worried is the speed the toolbars are growing. We're only just starting and the graphical objects toolbar already features 15 icons or so. The textures toolbar will have many icons as well. What i'm getting at is that maybe we should split the toolbars a bit more. I don't know, maybe basic geometric solids in one toolbar, complex shapes (blobs, patches, meshes, lathes, etc.) on another, globally valid objects like translate, rotate, scale and comment on another, etc. That way the user can individually select what he intends to use, uncluttering his workspace much more. - Maybe this it's still a bit soon but, at least in the camera view, there should be a way to hide lines in the object, instead of seeing the whole wireframe. I mention it now because I don't know if it can have impact on the definition of each of the objects or just on the rendering on the camera view. - How hard would it be to assign a different color to an object on the wireframes? This, with the addition of the previous one, would make the preview much more useful. - Zooming and Translating the views. Right Click+'select from menu' is a bit cumbersome. Using alt+drag and ctrl+drag would be better IMHO. Shouldn't need much work I think. - Regarding includes (collections of textures come to mind here), this is a sketch of how I see it implemented: PMInclude, which basically has a file name for the include file. When a PMInclude is inserted on the tree and a file is associated, it parses the file, adding every thing inside it as children of the PMInclude. The serialize*() methods shouldn't go through those children , instead it would just output the PMInclude's values. Also, editing on that entery branch should not be allowed. This is not very urgent, since, as it is now, we can just drag'n'drop the textures we want from one file to another very easily.

Regards, Luis

List archive and information: