1600x1200 -- but you need either a really large screen or an extremely crisp LCD (the latter, in my case). Its a great resolution for graphics apps, though.

Cool application of GA to a 3D problem. Genetic Algorithms have definitely proven to be great at stochastic optimization over constrained problems with very large search spaces. Have you considered trying to optimize over time as well, for animation purposes? Probably pretty difficult, as the search space explodes even more and a fitness function is probably harder to define. Might make for some interesting research tests though :) -Jeremy

A few thoughts:

Building an application like Poser or DS is a very large undertaking. Having designed and built a 3D application of a comparable scale to what you are talking about, I can tell you that you are looking at a minimum of a couple years of development with a dedicated core of at least several developers. The time it has taken DAZ to get to a decent alpha on studio is a testament to this, as is the overall amount of time that has gone into Poser over the years. Could this project be done as an open source project? Sure. It is just a very large job, and regardless of the number of overall contributors, would depend on a few very competent and dedicated core developers to drive it and push it along. Given that, it's certainly possible.

If I were to think of building such a project from scratch, I would probably build on top of wxWindows rather than QT, but QT is certainly up to the task as well -- it's more of a personal preference. I would also probably build on top of an existing open source scene graph rather than building my own (unless you want to do it just for the experience). OpenSceneGraph is a decent open source scene graph that wraps OpenGL, and it can integrate easily with wxWindows. Building a C/C++ plugin interface would of course be ideal, though it is a fairly difficult thing to do well, but integrating Python is simple to do. Actually building a good Python API takes a good deal of time, as the auto-API-generators don't usually quite give you quite what you want, but its a straightforward process.

If you are greatly concerned with having full control over the core of the 3D application itself then rolling your own is certainly the way to go. However, I would have to agree with what some others have said in this thread. You may find it a more rewarding expenditure of time and energy to either write plugins to DS when the SDK becomes available, or extend Poser via the Python interface (the recent work from WeirdJuice gives an idea of how far you can actually take this). Or, if you want to build a whole new posing engine, it may be more rewarding to build a character posing and/or animation plugin for a general 3D app. That way you do not have the burden of building the supporting framework of the entire 3D application, but rather just the part that you want to do well. If you're not into targeting an expensive high-end app like Maya, MAX, Lightwave, Cinema, etc., even something like Carrara has a pretty good plugin SDK. This approach at least gives you a (fairly) stable basis to build on, rather than having to construct all that yourself.

I also have to wonder if ryamka is largely correct regarding the community that would like to see an open source poser-like program built. I would think that if the community were full of software engineers with a background in 3D programming that we would see a much larger group of people creating Python-based extensions for Poser itself. Those I know of that do have the abilities seem to be generally involved in commercial projects. Maybe a misconception -- I dunno.

Anyways, just felt like dropping my $0.02 on the subject.

-Jeremy

I guess another way to do something similar to what I've done here is to duplicate each light and set one copy of each light to raytrace and one copy of each light to shadow map. Then you get a shadow-mapped shadow overlaying your raytraced shadow within a single render. In a quick test, that doesn't produce quite as nice of a result as blending the two different renders on one's own, but would be a little easier to automate, and does look better than either just raytraced shadows or just mapped shadows, at least in an image like the one above. Raises the render time, of course.

And here it is with shadow maps only. Neither gave the result I wanted straight from the renderer. The blend I did was actually really quick and dirty -- a little more time spent could probably produce better results. Stewer, do you know if there is enough Python access to the lighting system in P5 to acutally automate this in a script? I could go look myself, but since you were writing a lot of the later python extension methods, I thought you might know off the top of your head. Might be fun to play with, anyways :)

For comparison, here is the same image straight from the renderer with ray traced shadows only.

The problem with using shadow-mapped lights is that in some cases, you need ray-traced shadows. For example, in the image above, it would be impossible to get those wine glass shadows using shadow maps, because they depend on the fact that we are ray tracing through the glass material. The image above actually uses the following technique: render the exact same image twice -- once with all lights set to shadow mapped shadows and the second time with all lights set to raytraced shadows. Then blend the two images in photoshop or similar image processing app. That way you can get the benefits of raytraced shadow accuracy, but soften them by blending with the shadow-mapped shadows. It's a little more work, but if you have some transparent materials like in this image, it can make a difference.

-Jeremy

Here's what the same mushroom looks like saved as an OBJ, imported into Poser 5, given some really basic P5 procedural materials, and rendered in Firefly.

I agree that Wings is a very good modeler -- although it is strictly polygon based and cannot really do "holes". I think it is something you should try out and see what modeling paradigm best fits your own personal ways of thinking. There are numerous ways to create nearly identical shapes in different modelers. Wings has an interface that feels a little inaccessible the first time you use it, but once you learn just a few things, it is really quite fast. I'd say download it and try the first wineglass tutorial on the Wings site. Wings happens to appeal to my way of thinking, I guess. Outside of perhaps the CD cover version of Cinema, I think it is probably one of the best free modelers available. Here's a mushroom made in Wings -- took me about 20 minutes, I think.

I think CL may feature a story about this one on their site, but I still have to mention the short "Same Difference". You can see two excerpts of it

"http://www.soulhill.com/all_the_SAME.mov"

and

http://www.soulhill.com/DIFFERENT.mov

The full animation is around 13 minutes. It's done mostly in Poser, and I believe that the excerpts above were even rendered in Poser 4. It's a very cute story with nice animation. Of the two, I particularly like the second excerpt :)

OK, I don't usually post here, but I have to make a comment on the post that states that undo functionality is one of the simplest things to code. I have been a professional software developer for 16 years, delivering shrink-wrapped applications, and the complexity of designing and coding undo functionality depends hugely on the application domain. I agree that writing a good undo, even multi-level, is pretty straightforward for some applications (something like a 2D image editor or a text editor, for example), but the more complex and interdependent your data structures are, the more difficult undo becomes. In fact, getting a multi-level undo system right across all facets of a large application in a way that is efficient can be one of the hardest things to do. This is not to say it can't be done. It certainly can, and it should. But it is infinitely harder if the application architecture is not designed for it from the beginning. Adding multi-level undo to an application like Poser that was not designed with that in mind is a very tough job. It's not that people at CL don't know how to write a good undo system. CL's pro-V Studio has a very memory-efficient 100 level undo system, and it, like Poser, also must manage very large and complex data structures. However, although it shares many basic libraries with Poser, it was a new application and was designed and architected from scratch in the last couple of years. As such, the whole structure of how the app works was designed to support complete multi-level undo, which is what made it possible to implement. Even then, a good deal of development effort went into getting undo right, particularly for things like copying and pasting multiple object selections (other features people would like to see added to Poser). So Marc is not overstating the difficulty of adding app-wide multi-level undo to Poser.

That said, I think it is a very important feature to add, and it would be a great addition to P6.

A couple of notes regarding the basis for what I am saying -- I was an engineer at CL until the last layoffs, working primarily on pro-V Studio. Also, I think this has probably been mentioned by someone before, but in case anyone is wondering, there are good reasons why CL developed pro-V instead of spending the same development resources on Poser. In fact, pro-V had a very small development team compared to Poser until the last couple months of its development, after P5 had shipped. Finally, this is not a "don't say anything bad about CL" post -- it is just to clear up that Marc's statements about the effort required to improve undo in Poser are quite factual.

-Jeremy