Quote - ...The last project, well, my french is a bit rusty but from what I gather it's actually not related to Poser at all, even though the word poser does appear in the description.  It's actually a content engine for free content for websites.

That's exactly right - 'poser' in this case is the infinitive form for 'to place'... roughly... get that a lot, when doing a Google for things 'Poser'....

Hello RenderDog,

I'm a professional programmer and user of Poser, Carrara, Vue, and others. Personally I don't like working on the GUI part (too much effort) of any application but do consider participating in any Open Source project involving a replacement of Poser. Poser is outdated and would need to be reworked to get it ton an acceptable standard, something I don't see happening. DAZ Studio would have been great if they had opened it up more the available API is just too limited (an API should allow you to change the GUI in whatever you desire).
Currently looking into Blender3D as a possible environment but hating to have to use keyboard shortcuts (I work with too many applications to ever remember the shortcuts, have a hard enough time remembering the VI shortcuts). Initially I did consider if attaching to Blender made sense but I don't feel the GUI improvements are likely to be enough to convince me to use it.
When you have a proposal for the GUI and a bit of design for the development environment and interfaces I would like to consider if I feel like participating. Too many conflicting interests at the moment to commit to the project at this moment. When you have convinced me you are serious and it is developing in a way I believe is viable, I would be willing to invest time to study the requirements and actually code some part of it.
I have seen many great pieces of 3D programming both in demos and in actual code. A lot is possible nowadays and I would like to participate when I can believe there will be a result in a foreseeable future.

Hope you get going soon and hope to see something in writing.

Quote - Hello RenderDog,

I'm a professional programmer and user of Poser, Carrara, Vue, and others. Personally I don't like working on the GUI part (too much effort) of any application but do consider participating in any Open Source project involving a replacement of Poser. Poser is outdated and would need to be reworked to get it ton an acceptable standard, something I don't see happening. DAZ Studio would have been great if they had opened it up more the available API is just too limited (an API should allow you to change the GUI in whatever you desire).
Currently looking into Blender3D as a possible environment but hating to have to use keyboard shortcuts (I work with too many applications to ever remember the shortcuts, have a hard enough time remembering the VI shortcuts). Initially I did consider if attaching to Blender made sense but I don't feel the GUI improvements are likely to be enough to convince me to use it.
When you have a proposal for the GUI and a bit of design for the development environment and interfaces I would like to consider if I feel like participating. Too many conflicting interests at the moment to commit to the project at this moment. When you have convinced me you are serious and it is developing in a way I believe is viable, I would be willing to invest time to study the requirements and actually code some part of it.
I have seen many great pieces of 3D programming both in demos and in actual code. A lot is possible nowadays and I would like to participate when I can believe there will be a result in a foreseeable future.

Hope you get going soon and hope to see something in writing.

Not to worry about the GUI part, I was already planning on tackling that myself.  Daz Studio I think is a nice enough idea, but I had some pretty good reasons for opting to code something from the ground up as opposed to doing something like plugins for DS.

First and foremost of course would be both to have an app that would run natively in Linux and second of course to have an app that is truly open source, and as such could benefit from a steady stream of "new blood" and "new ideas" as the project progresses.

Also the notion of paying a hefty sum for an SDK for DS, writing plugins for them and being more or less hamstrung into there UI just didn't appeal to me much, particularly since I dislike there UI on the whole.

So I thought a new open source project was probably the best bet all the way around.  I agree with you about blender, plus blender from what I've seen seems to concentrate more on being a "3ds Max" like application.  My goals for this project aren't so much aimed at the professional graphics artist and animator as they are at folks like myself, the hobbiest.  I want something that is simple to use and takes care of a lot of the heavy lifiting for me.  I want to be free to pose, create and render, and not spend nearly as much time tweaking, morphing and rigging.

Don't get me wrong, I think it will probably develop a following of professional graphic artists as well, but truly the design concept here is an app that is powerful and fully featured but easy to use even for people who don't have a ton of graphics experience. 

So my design philosphy is quite a bit different than Blender, again one of the reasons I decided to code from the ground up rather than make plugins for a pre existing applicaiton.  As to written proposal, I've already started one, more or less a guideline on project development, goals for various development stages - basicly features that i'd like to include and which stage of the project I'm planning on beginning implemenation for each, that sort ot thing.

It will also include coding guidelines and concerns, libraries that I'm planning to include in various project stages, etc.  It will be about half proposal and half notes that I myself can refer back to to make sure that things are progressing as planned.

I'm hoping to have it finished shortly, when I do I'll upload it to sourceforge and provide a link that you, or anyone else who might be interested in joining the project, can peruse so you can get  a better idea as to what the overall development plan is.

Quote - Hope you get going soon and hope to see something in writing.

Ok, got a quick and basic proposal in writing, a lot more detail to add as I go but this will give you the basic groundwork and scheduling I have in mind.  Feel free to peruse it (indeed, this includes not only yourself but any other interested parties) and get back to me with any questions, suggestions or concerns you might have.

**
Figure Animation Studio (FAST)**

Project Proposal and Design Notes

Overall Design Philosophy:

The overall design philosophy of Figure Animation Studio is to provide 3d graphics artists with a set of well integrated, easy to use tools to pose, render and animate 3 dimensional objects with particular emphasis on human figures.

The project will be designed as an alternative for commercial programs like Poser and Daz Studio. It will be fully compatible with files that were created and designed for use with either of these aforementioned programs, giving it a huge base of available content and allowing those who have already invested a great deal of time or money into building a large amount of content for Poser or Daz studio to make use of said content without the need for either Poser or Daz studio.

Since Figure Animation Studio is a 3d graphics program, particular emphasis will be placed on two areas when designing or reviewing code submitted for this project.   The first an most primary concern will be in the area of memory management. 3d applications of this nature utilize a great deal of memory to perform certain tasks, and as such routines/functions/modules/classes should all be written in such a way that memory is used in the most efficient way possible.

Requiring a few additional “passes” when, for example, reading an object file, is far preferable to a method by which the file is only read once, but a great deal of memory is wasted filling variables with blank statements or null data. Whenever possible the code should follow the simple axiom, if memory is not actually necessary, it shouldn’t be allocated. When an object in memory is no longer necessary, it should be destroyed. 

The second area of particular concern in the design of this particular program will be cross platform compatibility. Figure Animation Studio will be coded from the ground up with the expressed purpose of being able to run on either Windows or Linux as a native app, and the possibility that it might at some point be ported to the Macintosh system as well.

Thus any libraries chosen should be chosen with this design criteria in mind, that they should provide cross-platform capability whenever possible. Coding that is specific to a single platform should be avoided, the source code should be able to compile on either linux or windows (and hopefully eventually mac) without source code changes or branches if at all possible.

Last but not least Figure Design Studio will be coded with the idea of keeping the GUI separate from the actual inner workings of the program whenever possible. OOP is a must, functions/features should be encapsulated into logical classes and the actual graphics interface should be a separate concern.

Design Stages:

Stage I:  Project Beginning to Alpha Stage

** **

The Figure Animation Studio Development will begin with the very basics. To start with it will require a module to read in all files (CR2, PP2, PZ3, etc) designed for use with Poser and utilize them just as Poser or Daz Studio would.

This will include being able to load and display all of the various figures, the ability to load morphs, injections, poses, materials, etc.

The alpha stage development will concentrate on the very basics of being able to read in Poser/Daz studio files, being to be able to pose/manipulate/design a scene using these objects and then being able to render them as a static image.

All geometry information that would cause a Poser or Daz Studio figure to change such as INJ files or character morphs should be readily accessible and functional in the alpha stages of the project. At this stage FAST must also be able to pose the figures, requiring it to understand Posers bone structure, mesh deformation and additional considerations such as ERC and JCM’s.

Figure Animation Studio must also be able to save these files either in it’s own native format, Poser format or Daz Studio format for maximum compatibility with both programs.

Should this stage of development prove to be progressing too slowly support for Daz Studio might be pushed back to a later stage of development, however support for Poser files is a requirement for the Alpha stage to be considered complete. 

Also, while I would like to have at least the basics of an internal render engine complete for the Alpha release, again should initial coding fall behind schedule this is something that can be moved back to a later stage, provided FAST can be successfully integrated with other Open Source rendering options such as yafray, sunflow, etc.

Eventually I would like to have fully featured, network aware, internal rendering engine in addition to having the ability to transfer render data quickly and easily to external rendering engines like the ones mentioned above, giving the end user a multitude of rendering engines available for use with FAST.

As such I think it would be prudent for FAST to be able to send render data in “Blender” format, since at the moment most open source projects of this nature are designed to work with Blender.

I’d like FAST to be able to read and write as large a variety of 3d file formats as possible. It’s own internal library should be able to read Poser runtimes and store information like path’s and file locations as well as file references within the database itself.

One of the features that FAST will have is the ability to open CR2 or other files of that nature and check all of the internal references (obj files, material files, etc) and build a database of these file locations.

This database can then be used for several things – first a safe move or delete feature. Should the user decide he wants to move a file from one poser runtime to another, he/she can simply select the file and select move. The database can then be accessed and all of the internal references checked. If another CR2 (or equivalent) file contains references to lets say the same texture file, FAST can then alert the user and ask them if they want to just copy this file, and let them know if they chose to truly move it that another CR2 will be affected should they try to access it at a later date in Poser or Daz Studio.

Safe delete will work in much the same fashion, it will check all the references in the CR2 and should no multiple references in the database be found it will delete all of the files associated with that CR2 from the runtime. 

This database can also be used for integrity checking, making sure that all of the files/objects referenced by the various CR2’s exist and are where they are supposed to be. 

This will also provide a method by which FAST can rapidly find and open files referenced by a CR2 or PZ3 file without having to search through all Poser runtimes for the correct files, which should speed up loading of Poser content a great deal.

The library interface should also allow you to move, create, delete or change directories/items within a poser runtime quickly and easily. 

The database will also give another added advantage in that by including a system by which items can be placed into various “categories” it would be possible to group items even across multiple runtimes by common themes, with the final library display being filtered by these categories when they are selected.

For example, you might have one runtime that included some clothes that could be classified in the database under the category “Genre” and the subcategory of “Sci Fi”, and has an additional category of “Type”, “Clothes”

In another category you might have some props, like perhaps a ray gun, that are also classified as “Genre” Sci Fi” and an additional category of “Type” “Character Props”.

This would allow you while working in the library to display everything in the “Genre, Scifi” and it would show both of these items, even though they are not in the same Poser runtime.

If you further limit the filter by adding “Type, Clothes” then only the clothing would appear, the prop would be filtered out because it has a different type than clothes.

A list of common, already available categories might include:

Figure (Which figure is this for, M3, D3, A3, A4, etc)

Type (What type of item does this apply to, clothing? A character? A prop for a character? Etc..)

Gender (Male, female, none or neutral)

So, one could find everything (Characters, mat poses, etc) for a Figure like M3 even across multiple runtimes by selecting a filter of Figure, M3.

If you were only interested in figures, props, mat files etc for clothes for M3 you could add an additional filter of Type:Clothes and then all of the additional items (Like character Poses, Mat files, etc) would be filtered out. Only those files that applied to clothing would be shown.

The categories themselves can be edited by the user, so they can change or add categories or subcategories to fit best with there own style of organization, however the “default” categories will be stored separately in an XML file so should the user ever desire to do so he/she can easily restore the default categories with the click of a mouse.

During the alpha stage I will also code a TCP/IP server for FAST, one that can be switched off should the user so desire. The TCP/IP server will allow any external program from a valid source (determined by IP masking if desired) to access FAST and make use of all of it’s features from an external program.

This way FAST can very easily be extended by Python, C++, Java, etc – any programming language that can send and receive information via sockets can be used to make “scripts” or “add ons” for FAST. 

Stage II: Alpha Release to Beta Stage

The Alpha release will be a good opportunity for people who are very interested in the project to peruse the work to date and offer feedback and hopefully additional support. Once the Alpha stage has been reached, development should then proceed into more difficult areas of the project. The internal rendering engine should be expanded to include abilities such as the ability to render across networks or make use of “clusters” of machines to render a single image.

In Stage II the ability to do animations will be examined and hopefully implemented. This stage of the project will concentrate on providing a simple animation interface and the ability to export a completed animation into various formats including mpeg and possibly flash as well.

This will also be the point in the project where the rigging tool is implemented, it should be easy to use and integrate well into the rest of the program. Unlike Poser or Daz Studio, users should NEVER have to resort to editing files like CR2’s in order to implement features if such a thing can be at all avoided.

The rigging interface should be able to do IK Chains, things like ERC and the like should all be able to be manipulated from within this interface. A product put out on Renderosity called “Easy Pose” should give you some idea as to the basic functionality I’d like to include all within the rigging interface. This is a primary focus of Figure Animation Studio and one that will set it apart from other programs, it will have a powerful but easy to use rigging interface that will allow figures to be made poseable with a minimum of effort.

Should work on the rigging interface be going well and should the time present itself I would also like to spend some time at this development stage to work on the morphing interface. I would like tools like “magnets”, “wind force”, and the “morphing brush” to be available in this area, as well as a basic modeler that is specifically designed to allow the user to work with human figures and create there own morphs quickly and easily.

This will not be a full blown modeling application persee, it will not have all of the features of say blender or 3ds max. This will be specifically designed to create character morphs, and it’s gui and features will be built for that purpose.

Saving a full body morph or creating an injection channel when it is finished should be simple menu options, on click and it’s done. While it will still be possible to save the individual morphs to individual body parts one by one, it should not be necessary to save all individual morphs, dial them in, create a full body morph and then save. A simple click should allow you to select a list of morphs from all of those currently applied to a figure, group them together as a single morph and save them as either an INJ channel, a full body morph, or both.

The same philosophy will apply to saving MAT/MOR Poses – this should be a simple, one function that allows the user to select either all of the MAT’s for a figure, or even just specific mats/mors should they desire. There should not be a need for external scripts to perform these functions, the programs UI should make it easy to do from the get go.

The completion of the beta stage should provide a more or less complete but basic application that can be used to easily load, pose, and render either still’s or animations using the internal rendering engine, and make use of external rendering engines to the utmost of there capabilities.

Once this is accomplished a beta version can be released to the public, allowing them to find any potential problem areas and make any suggestions they might have for improvements.

Stage III: Beta to First Release

** **

At this stage we’ll have to start being a great deal more flexible to provide for both bug fixes and “user wish lists”. It is at this stage where I’d like to start looking at things like a second modeling applet, this one specifically designed with clothing in mind.

It would integrate with the rigging interface, and allow the user to quickly and easily select basic models for things like shirts, pants, skirts, shoes, etc and modify them to suit their individual needs and styles.

Again unlike conventional full blown modelers, this one would be specifically designed to model and manipulate clothing for human figures, allowing the artist to easily do things like “add wrinkles”, “create pleats”, etc, etc..

By first loading the figure and then a basic clothing type (long sleeve shirt, short sleeved shirt, etc) it would be possible to create a wide variety of clothing very quickly using a very simple modeling applet.

The rigging interface will be designed so that the clothing would already have the “basic” rigging of the underlying figure, and additional rigging for moving skirts, opening shirts, etc could be included with each basic clothing figure type.

Once the modeling is finished the user could then open the “rigging interface module” and make any adjustments they might need as far as rotation points, etc, should they want to do something a bit fancier than just the basic rigging already provided.

At this stage I would also like to integrate a cloth simulator, both for use in standalone mode and for use with the modeler to produce more realistic clothing effects.

Also if at all possible I would like this cloth simulator to work on full figures, not just single objects. It would treat the figure like an object for the purposes of cloth simulation, but retain all of it’s rigging data for later use, making the Poser requirement of exporting a figure to an obj, reimporting it and then running the cloth simulator obsolete.

Stage IV: Initial Release

** **

By this stage we should have all the major kinks ironed out and a very capable posing and rendering application that works out of the box on both Linux and Windows with both DS and Poser files.

After the initial release I can think of a lot of features I’d like to add down the road for additional releases – for example a face room that actually works on a variety of figures, allowing you to produce a usable 3d representation from 2d photographs in a much easier fashion that add ons like Face Shop Pro do now.

I would like to add a full blown modeling applet to be used for modeling items other than clothing or character morphs, again sticking with the easy to use interface of the original app but adding more generalized functions used by more traditional modeling apps as opposed to the very specific, tailored functions of the Morph Designer or Clothing Designer modeling applets.

C++ Libraries and Platform Info

** **

After investigating a myriad of possibilities I think the best 3d library to use would probably be OGRE, it provides most of the functionality needed for creating/editing scenes, cameras, lights, etc with a minimum of fuss, and is cross-platform capable.

ODE will be used for things like windforce, gravity, and other calculations that will prove very useful. While the initial releases will probably only make minimal use of this library, for future releases it will provide a wealth of capabilities particularly in the animation arena.

The main portion of the GUI will probably use a combination of OGRE and QT – again QT is cross platform, has a very easy to use form designer and should speed up development a great deal. While I actually prefer glade/gtk from a licensing standpoint, QT provides some advantages, such as Mac compatibility, that gtk does not.

At the moment on Windows I can compile for both 64 and 32 bit versions, and for Linux I can produce Debian packages for 32 bit. I’ll be looking for volunteers to compile and maintain packages for other Linux distributions and hopefully for Mac OS-X and hopefully I’ll be able to have them on staff prior to the initial release.

This covers most of the basic project information, there are other features that I’d like the program to have that are not covered yet in this document, it will be a work in progress like the app itself, but this covers most of the basic design elements and philosophy.

Bravo!  Bravo!  Bravo!
DPH

In your proposal I am missing information about when you propose to tackle the dynamic features (hair and cloth) and the material nodes. I do assume you do not intent to handle this in the first stage but you will need to address these issues. Furthermore a lot of people would like to know if you would be able to handle collisions in a friendly way and things like fluid and soft body dynamics. These are areas where Poser is very weak.

I understand you don't intend to develop a fully fledged modeler and I do expect that such a modeler will probably be available quite soon in the project as a plug-in (several are available so it is likely that someone would integrate an existing one) but should provide a capability to create morphs and design clothing as soon as possible as these appear to be common wishes of all initial users.

Personally I would not spend effort in developing a renderer in the early stages but instead use a renderer already available. Any developed renderer should always be just another available renderer as you should strive to support as many available renderers as possible (including whatever material setup they require). It will be important to understand and correctly handle the materials (with all nodes) used in both Poser and DAZ Studio and to convert these to the materials as appropriate for the different renderers (this will likely be one of the major challenges). In the first stages only support for the most basic materials is required.
Animation is a nice to have but most people using Poser have no need for animations as they mostly produce stills only. Currently within Poser it is required to set up an animation for the calculation of dynamics, I would prefer to remove this requirement as it is unclear to many users and would propose to handle this in a modifiable draping (which is in effect an animation but can be provided in an easier way).

Cloning of object is also important and should happen automatically, when another copy of an object is added it should become a clone. The system should also be intelligent enough that common materials should actually be shared unless specifically disconnected. This means that if you add a chair to your scene and than add another of the same chair, they be become cloned objects, if you then add a table using the same basic wood material, the materials become shared, so changing the wood will automatically change both chairs and the table.

When defining the GUI make sure you include the dials as they currently exist in Poser (although people complain about them, they equally complain about other applications not having them) together with some other options like numeric entries only and sliders, for angles a clock face with a line would be convenient. Please allow model developers to provide a capability to hide specific variables and to allow only specif values or value ranges for specific variables.

In all a good start.

Quote - Animation is a nice to have but most people using Poser have no need for animations as they mostly produce stills only.

Only because Poser's animation and scene navigation is a pain to use.  I animate, but if the interface was improved, lots more folks would too.

Sounds good!
There's some functionality mentioned, like MAT/MOR pose creation and saving, that's currently available via standalone addon products (INJ Pose Builder, MAT Pose Creator), but also via Python scripts.
I've got a couple of Python scripts, both publicly available in freestuff and some not-ready-for-release scripts on my hard drive. You're welcome to use any and all of my Python scripts as a roadmap for this functionality.
Something that could be useful: a multiple delete tool. Ockham has/had some Python scripts out for deletion of multiple props/figures, I've adapted one of those scripts, and I use them on a regular basis. Could be extremely useful.

As for rigging tools, I completely agree that something better than the Poser Setup room would be a great asset. There's some rigging tricks that I use that fall into the realm of "CR2 hacking", like illegitimate welds, internal point-ats, grandparent/grandchild and sibling/sibling joint parameters.
While it seems obvious to me that the regular (sort of) documented features of CR2 rigging should be supported and implemented in FAST/Rigging, maybe these undocumented tricks shouldn't be included.

As for the inner workings of rigging, morphs, bones and joint parameters, I can highly recommend the book "Secrets of figure creation" by B.L. Render. It clearly describes how it all works, so it could give you a good idea how to implement it all in FAST.

The library database feature looks cool! There might be some problems though. How do you keep the database synced with the actual folders? How do you handle libraries on removable devices or on a network, libraries that aren't always available? What about content that doesn't follow the rules when it comes to object/texture references (many, many freebies, and some older marketplace items don't use the correct relative reference scheme)?
I'm not saying it's impossible, I'm just saying it requires some thought, and it probably requires a resident folder monitoring utility - which will be OS dependent.

Quote - In your proposal I am missing information about when you propose to tackle the dynamic features (hair and cloth) and the material nodes. I do assume you do not intent to handle this in the first stage but you will need to address these issues. Furthermore a lot of people would like to know if you would be able to handle collisions in a friendly way and things like fluid and soft body dynamics. These are areas where Poser is very weak.

The dynamic cloth simulation will be handled hopefully between the alpha and beta stages (apologies, thought that was mentioned somewhere in the proposal, have to go back and reread it and see if I can fix that)  Dynamic hair probably won't be addressed until some point after the beta stage, possibly not until after the first release depending on how well other areas of the project are going.

The collisions and dynamics portion is also somewhat up in the air at the moment, I'd like to include some powerful, easy to use features in this regard but this is one area of the project that will be something fairly new to me, so more reading and research will be required before I can truly give a complete answer on that question.  Its something that will be worked into the project, just can't tell you exactly when as I haven't yet had the opportunity to research it properly and make a determination as to just how difficult that will be to code.

Quote - I understand you don't intend to develop a fully fledged modeler and I do expect that such a modeler will probably be available quite soon in the project as a plug-in (several are available so it is likely that someone would integrate an existing one) but should provide a capability to create morphs and design clothing as soon as possible as these appear to be common wishes of all initial users.

I'd like to give it it's own modeler eventually, probably after the initial release, but to start with I'd like simple model applets that are pretty much focused on there own individual tasks.  If done properly it shouldn't be cause for much duplication of code, all of the modeling funcitons for both applets and eventually the main modeler can all be built on the same classes.

But the smaller,  more specialized modeling features I think would be of huge benefit to a lot of people.  A lot of folks want to be able to model clothes or make minor adjustments to them, or model characters and make minor adjustments to them, but no everyone really wants to go through the time consuming process of learning how to do all of this in a full blown modeler application.  In this way you can make such adjustments on the fly with easy to use, built in tools specifically designed for this purpose. 

Quote - Personally I would not spend effort in developing a renderer in the early stages but instead use a renderer already available. Any developed renderer should always be just another available renderer as you should strive to support as many available renderers as possible (including whatever material setup they require). It will be important to understand and correctly handle the materials (with all nodes) used in both Poser and DAZ Studio and to convert these to the materials as appropriate for the different renderers (this will likely be one of the major challenges). In the first stages only support for the most basic materials is required.

Well the rendering engine is the lowest priority item in the earliest stages of development to be sure, since there are already a lot of other rendering engines out there in the open source realm, but provided there is time I would like to focus at least some of the initial development in this area so that hopefully even for the alpha release there will be a basic rendering capability available internally without the need for downloading and installing additional packages to make the program truly functional.

Quote - Animation is a nice to have but most people using Poser have no need for animations as they mostly produce stills only. Currently within Poser it is required to set up an animation for the calculation of dynamics, I would prefer to remove this requirement as it is unclear to many users and would propose to handle this in a modifiable draping (which is in effect an animation but can be provided in an easier way).

I'll have to give that one some additional thought, on how a modfiable draping system might be implemented for animation purposes - the keyframe technique is pretty straight forward from a programming perspective and is pretty well roadmapped already in other apps, but the second technique might be interesting if I can get it to work right.

Quote - Cloning of object is also important and should happen automatically, when another copy of an object is added it should become a clone. The system should also be intelligent enough that common materials should actually be shared unless specifically disconnected. This means that if you add a chair to your scene and than add another of the same chair, they be become cloned objects, if you then add a table using the same basic wood material, the materials become shared, so changing the wood will automatically change both chairs and the table.

Interesting - so in the "material room" have it so you can list items and there associated materials, or list materials and there associated items, and associate or dissasociate them as needed.  I'll have to give some thought as to how to make this fairly straightfoward from a UI perspective, but I love the concept.

Quote - When defining the GUI make sure you include the dials as they currently exist in Poser (although people complain about them, they equally complain about other applications not having them) together with some other options like numeric entries only and sliders, for angles a clock face with a line would be convenient. Please allow model developers to provide a capability to hide specific variables and to allow only specif values or value ranges for specific variables.

Content developers will have complete control of the final output, being able to easily group items, change the names of or add/delete any of the dials, etc. 

Intiially I was looking at the slider controls more akin to those in 3ds max, where you can either type in the value or use the up down arrows to slowly increment or decrement it.  Also rather than using posers scale of 0-1+ I think I'd prefer a percentage system for all dials/controls (0-100%+).  I suppose I could make this a selectable option for others.  I think it might also be possible to make dials/sliders a selectable option, allowing the end user to use whichever he/she prefers, have to give that a bit of thought and see what can be done there.

Quote - I've got a couple of Python scripts, both publicly available in freestuff and some not-ready-for-release scripts on my hard drive. You're welcome to use any and all of my Python scripts as a roadmap for this functionality.

Greatly appreciated, I'll check them out as soon as I get the opporunity :)

Quote - Something that could be useful: a multiple delete tool. Ockham has/had some Python scripts out for deletion of multiple props/figures, I've adapted one of those scripts, and I use them on a regular basis. Could be extremely useful.

I like that.. I also like the idea of being able to move, rotate, delete, rescale, etc..  items selected
from a list that are not necessarily parented to one another.  Avoid the hassle of parenting an object to make it easier ot move and then unparenting it later to avoid any problems that the parenting may cause down the line (like visibility, etc).

Quote - While it seems obvious to me that the regular (sort of) documented features of CR2 rigging should be supported and implemented in FAST/Rigging, maybe these undocumented tricks shouldn't be included.

As for the inner workings of rigging, morphs, bones and joint parameters, I can highly recommend the book "Secrets of figure creation" by B.L. Render. It clearly describes how it all works, so it could give you a good idea how to implement it all in FAST.

Lol.. well if the undocumented stuff is included it will probably be later on, need to focus on the stuff that is documented first and work into the trial and error realm later.  But FAST should have a smart, powerful, easy to use rigging system.  It is the one area that most other applications truly do lack, while many of them have rigging systems I haven't seen too many that I really like and almost all of them lack features I consider to be essential.

Quote - The library database feature looks cool! There might be some problems though. How do you keep the database synced with the actual folders? How do you handle libraries on removable devices or on a network, libraries that aren't always available? What about content that doesn't follow the rules when it comes to object/texture references (many, many freebies, and some older marketplace items don't use the correct relative reference scheme)?
I'm not saying it's impossible, I'm just saying it requires some thought, and it probably requires a resident folder monitoring utility - which will be OS dependent.

Yes, the removable drive thing does present a bit of a challenge, but not top bad overall.  At the moment everytime you open a poser directory it does a directory list from the OS and then displays the results.

The database will work in a similar fashion, when retrieving a list from the database it will check for the existence of the "CR2" file along the indicated path, if it doesn't exist it will still be listed, but possibly greyed out to indicate that it is on a removable drive/path.

If you click on it to load it while it is in this state, the program could check to see if the path itself existed, a dialog would pop up indicating that either the path is there but the file was not found or that the path was not accessible indicating it's probably a network/removable drive that is not currently accessible.

In future releases it might even be possible for the system to get a bit smarter, include a flag in the database for items on removable drives (like DVD or CD's) and have a "reference hint" field, if you select an item in the database that is so marked it will prompt you to load the DVD/CD in question and use the "reference hint" field so that it could give you information on how that particular DVD/CD might be labeled as well.  For example, if you were to create a collection of DVD's that were numbered, when you add the DVD content to the database you could tell the system that this is on a removable drive, and put tell it the # you have printed on the DVD label.

The system would then add all the content on the DVD, flagging it in the database as being on a removable drive and setting the string stored in the reference field to something like "Please insert the DVD/CD labeled "Poser Content Disk #1" into your DVD drive"  The string would be fully editable of course, so you could have that particular prompt say anything you'd like when you try to access content stored on removable media.

Bookmarking thread before I forget - got some reading/catching up to do here :)

Quote - Intiially I was looking at the slider controls more akin to those in 3ds max, where you can either type in the value or use the up down arrows to slowly increment or decrement it.  Also rather than using posers scale of 0-1+ I think I'd prefer a percentage system for all dials/controls (0-100%+).  I suppose I could make this a selectable option for others.  I think it might also be possible to make dials/sliders a selectable option, allowing the end user to use whichever he/she prefers, have to give that a bit of thought and see what can be done there.

I have actually produced a bit of a spec about controls for some other application. I'd like to share it here. Please don't make the same mistake as they did for Carrara where they have sliders with a range from 0 to 1 and don't provide the capability to set negative values or values greater than one with the slider (which do often make sense).

The concept of controls requires the need to view and change to value of the control in an efficient and accurate way.

Viewing the value of a control as a displayed value between 0 and 1 (with however many decimals) or 0 and 100 (as a percentage) isn’t really helpful when the real meaning is for instance a door where the value in degrees varies between 0 (completely closed) and 90 (fully open). Many other examples could be provided with varying values and meanings. In general it would be better to display the value in a meaningful way, as varying with a specific resolution between a minimum and a maximum value and possibly with specific texts if only specific discreet values are valid. This of course only provides a means of displaying a very specific value and does not provide any indication of the relationship between the actual value and the valid range of values (which would probably best be indicated with some form of slider).

As for changing a value there are contradictory requirements.

Typing a value is easiest if the value is easy to determine or is already known. Small changes in the actual value could be provided by nudging the value (for instance: arrow right would increase the value be 1 resolution step, arrow up would increase it by 10 resolution steps and page up by 100 resolution steps). This is acceptable for some applications but not really when dealing with intuitive movements.

For a quick selection of an indicative value in the range of possible values a slider is the best solution, it is quick but in general not very accurate. A slider is also useful for displaying the relationship between the actual value and the valid range of values. Furthermore is a slider a good way to select between several specific discreet values. These values can be indicated on the slider with markers and/or texts. A slider does not always have to be a straight line, it could also be a clock face where the slider moves around a circle with a line connecting to the center (this would be ideal for angles). Ideally such a clock face could also be only partially used, for instance when only an angle from 0 to 90 degrees would be valid a full clock face would be displayed with only a quarter marked as valid range, adding a text “closed” to 0 degrees and a text “open” to 90 degrees would make very clear that this is door that can be open or closed or anywhere in between. To set a value on a slider one can click anywhere on the slider line to set the slider to this value or one can grab the actual slider and drag it to its new value. Nudging as described in entering a value would also work.

For a gradual change a dial is more intuitive. To change the value of dial grab it anywhere and drag it in the appropriate direction. The rate of change should depend on the speed of dragging. This allows for very gradual changes but can take a while to make big changes in a value. Nudging as described in entering a value would also work.

Ideally the functionality of the three methods of changing the value of a control could be combined, so the actual value would be displayed in a text box, a slider line would be displayed with the actual slider in the correct position, and a dial would be displayed for fine control. When only discreet values are acceptable there is no need for a dial. When the slider is displayed as a clock face the dial should be centered in it as a kind of turning knob. On a slider it should be possible to set markers and/or texts at any value (as a reminder of reasonable values).

Just a suggestion about controls in 3D applications. In the text were also suggestions for combining two values to form controls in the shape of "squares" (two sliders) and "balls" (two dials), nudging required the use of the shift and alt keys. These have their applications but are probably not in scope for this project.

I very much like the zoom/pan controls in 3DS Max: panning by dragging the viewport with the middle mouse button pressed, zooming about the mouse cursor using the scroll wheel. Intuitive and fast.
Zoom functions that can be extremely useful: zoom to selection, zoom entire scene, zoom in/out (the latter should be a "mode", in which you can use left mouse+move up/down and the arrow keys to zoom).
The Vue method of dragging around the orthographic views for panning, combined with rotating the camera around the selection center (or scene center when nothing is selected) by dragging is also intuitive and very useful IMO.

And OGRE for scene preview - it would be wonderful. The amount of defail should be configurable by the user - low detail for quickly moving around even in more complex scenes, high detail for OpenGL quality rendering, especially useful for rendering animations.

OGRE supports an extensive array of mapping: normal mapping, parallax mapping, specular mapping, light mapping, you name it. More than Poser, much more than D|S. This mapping functionality is extremely useful for semi-realistic realtime 3D graphics, and will be a great asset to animators.
But most of the current Poser/ DS content doesn't come with all these maps, relying on detailed geometry instead. FAST could benefit from algorithms that derive these maps from the geometry, the same way that it is possible to generate a displacement map from a highly detailed ZBrush model.

I knew I had another text about file structures.
All these texts were written by me in diverse proposals, none where ever published or used in actual products (in my work I do spend quite a lot of time writing proposals which are never implemented or realized with other solutions for practical or commercial reasons). None of the texts were ever checked against already existing practices or patents.

File structure.

The XML file structure is well known and widely used. It has many advantages but also several disadvantages. As far as we are concerned the most problematic areas are the wastefulness of storage and the absolute openness of structure. The XML file structure requires using meaningful texts as tags (where the same text is repeated as the end tag), this makes the file in theory human readable but does create a relatively large overhead. In practicality most XML files tend to be so large that the argument of human readability is an unrealistic point anyway (a 10,000 line text with start and end tags often 1000’s of lines apart simply isn’t human readable). The overhead becomes event more problematic when a relatively small number of tags are repeated very often (as is the case in many structured data files). The structure of XML files allows using new tags at any place in file without any prior notification; this means files can not really be validated for valid content as there is no build in facility for providing a list of valid tags.

• Open Structure Data

In this proposed format the tags are replaced by numbers and the end tag is a single character standard token. The meaning of each tag number is maintained by a dictionary. This dictionary can be external but could also be contained within the file itself in special dictionary definition lines, where a dictionary definition is valid from its definition until the end of the scope of the element where it is defined. Since a number is generally shorter than a meaningful text (especially when the tags used most often get short numbers) and the end tag is a single character token the overhead is much reduced. Since an external dictionary can be used and dictionary definitions can be easily recognized in file validity of the file can be checked while still allowing for extensions and allowing for older versions which may not recognize specific tags (and could ignore those without causing problems for recognizing the file structure). This format can easily be converted to and from the XML structure.

• Native Structure Data

In this proposed format the tags (and other integers) are stored in the system native format, for the rest the same features as described for the Open Structure Data format apply. This means files in this format can only be properly read on the system they are written. This may look like a major limitation but due to a specific marker at the start of the file the exact encoding can be derived and the file can be easily converted to and from Open Structure Data format on any system. Additionally all numeric fields in this format are stored in the internal high precision numeric storage format (normalized with 2 digits per byte). Overall using this format increases speed of reading and writing, and will generally also mean a reduction of the file size.

• Minimized Structure Data

In this proposed format obsolete tags can be replaced by a single character standard token, for the rest the same features as described for the Native Structure Data format apply. Obsolete tags are defined as those tags which according to the dictionary would be the next tag after the previous tag. Any file in this format can easily be converted to and from Native Structure Data format. This format will significantly reduce the file size for most structured files.

• • Conclusion

Although the XML structure is a standard structure and widely used further study of possible file structures has revealed several alternative structures with advantages for highly structured files with repetitive content.

It is suggested that programs should only be able to read and write one of the proposed structures and upon recognizing a file in another structure call an external converter (since each proposed file structure will has its own unique markers at the start of the file it can be recognized). This allows the developers choosing the most convenient structure for their purpose without limiting the possible file structures.

This is the short version. I should be able to find a somewhat more complete design somewhere if you want a copy, although that probably wouldn't really apply anyway as the file wasn't intended for 3D data but for transporting logger data between diverse equipment. This was in the end implemented with a dedicated file structure.

Most proposals don't go much further that a short management summary and some technical notes as they are killed early on in the design phase. These texts are considered unfinished and are therefore not considered company trade secrets. As I work in the telecommunication industry it would be frowned upon if I were to use this in any related field but since this is open source work in a different field I am allowed to share any unfinished texts.
It is amazing that many design considerations are common regardless of the actual specialization.

Quote - I have actually produced a bit of a spec about controls for some other application. I'd like to share it here. Please don't make the same mistake as they did for Carrara where they have sliders with a range from 0 to 1 and don't provide the capability to set negative values or values greater than one with the slider (which do often make sense).

Not a problem there, the only "limitation" set on the controls are those specified by the artist, unless the figure creator intentionally limits the control it will allow for negative or positive values-

Quote -
Viewing the value of a control as a displayed value between 0 and 1 (with however many decimals) or 0 and 100 (as a percentage) isn’t really helpful when the real meaning is for instance a door where the value in degrees varies between 0 (completely closed) and 90 (fully open). Many other examples could be provided with varying values and meanings. In general it would be better to display the value in a meaningful way, as varying with a specific resolution between a minimum and a maximum value and possibly with specific texts if only specific discreet values are valid. This of course only provides a means of displaying a very specific value and does not provide any indication of the relationship between the actual value and the valid range of values (which would probably best be indicated with some form of slider).

Well, allowing a control to display either a percentage or an angle measurement I think would be easy enough, the difficulty would be in trying to do additional scales like feet, inches, meters, etc. 

I'll see what I can come up with, no gaurantees that would make the first release but it might be worth playing with just to see what I can come up with :) > Quote -

Just a suggestion about controls in 3D applications. In the text were also suggestions for combining two values to form controls in the shape of "squares" (two sliders) and "balls" (two dials), nudging required the use of the shift and alt keys. These have their applications but are probably not in scope for this project.

The controls I had in mind initially are like the 3ds max controls, a text box that you can type values into and two arrows (up and down) that allow you to increment or decrement the value and watch in real time the results.  I'll do a bit of playing around though and see if I can't possibly use these controls in conjuction with a more traditional style "dial" control as well. 

Quote - I very much like the zoom/pan controls in 3DS Max: panning by dragging the viewport with the middle mouse button pressed, zooming about the mouse cursor using the scroll wheel. Intuitive and fast.
Zoom functions that can be extremely useful: zoom to selection, zoom entire scene, zoom in/out (the latter should be a "mode", in which you can use left mouse+move up/down and the arrow keys to zoom).
The Vue method of dragging around the orthographic views for panning, combined with rotating the camera around the selection center (or scene center when nothing is selected) by dragging is also intuitive and very useful IMO.

And OGRE for scene preview - it would be wonderful. The amount of defail should be configurable by the user - low detail for quickly moving around even in more complex scenes, high detail for OpenGL quality rendering, especially useful for rendering animations.

OGRE supports an extensive array of mapping: normal mapping, parallax mapping, specular mapping, light mapping, you name it. More than Poser, much more than D|S. This mapping functionality is extremely useful for semi-realistic realtime 3D graphics, and will be a great asset to animators.
But most of the current Poser/ DS content doesn't come with all these maps, relying on detailed geometry instead. FAST could benefit from algorithms that derive these maps from the geometry, the same way that it is possible to generate a displacement map from a highly detailed ZBrush model.

I'm pretty excited about OGRE's capabilities thus far, some pretty impressive stuff.  FAST will be able to read and make use of Poser files, but it will also have it's own file format as well, allowing it to make use of some of the features you mentioned that won't be detailed in Poser's file format.

I like the idea of an algorithm that could read in complex geometry and generate detailed displacement maps - that could be a huge boon particularly in animation.  Allow it to read in the geometry, form and apply displacement mapping, and "flatten" the mesh so that the geometry itself would be greatly simplified. 

Again probably not something you'll see in the first release, but certainly something to look at for later on down the road.  The same technique though could also be a great boon to the clothes modeling applet, allowing the clothes modeler to keep the geometries pretty simple but still allowing them to have a tremendous level of detail.

However the clothes modeler would have to be able to do both, since I'd like the output from the clothes modeler to still be compatible with other programs like Poser and DS.   FAST is about giving people more power and options, not about taking them away.

I've also been giving some serious thought to giving the clothes modeler the ability to "fit" clothes to a figure.  Again this is not something that will probably be implemented right away, but in another discussion in a different thread we were talking about how new figures have a very tough time making it in the Poser / DS marketplace because vendors are not likely to create a lot of add on material for them.

As a resutl new figures have a very tough time catching on, even if they offer advantages over what is currently available.  I'm thinking it should be possible, with a bit of creative coding, to allow a conversion of clothing designed for one figure to fit another.  I'm still just in the planning stages here, this would require a lot of testing and much more consideration, but I think it might be possible to build a process of clothes conversion that would rerig as needed and even take advantage of cloth simulation to a certain extent.  It should even be possible to transfer morphs if desired, allowing you to fit pretty much any clothing to any character.

This one is going to take a bit of time to code of course, and probably won't make the first release, but it's certainly something I'd like ot add for future releases when time permits.

Quote - I knew I had another text about file structures.
All these texts were written by me in diverse proposals, none where ever published or used in actual products (in my work I do spend quite a lot of time writing proposals which are never implemented or realized with other solutions for practical or commercial reasons). None of the texts were ever checked against already existing practices or patents.

Read through your notes on file structure, I was originally considering XML particulalry for the TCP/IP server component to allow for ease of coding by 3rd party programmers, but after reading through I think perhaps XML might not be the best choice, but rather an easy to use API in various languages on both ends to allow for easy access to the file formats.

Quote -

Quote -
Viewing the value of a control as a displayed value between 0 and 1 (with however many decimals) or 0 and 100 (as a percentage) isn’t really helpful when the real meaning is for instance a door where the value in degrees varies between 0 (completely closed) and 90 (fully open). Many other examples could be provided with varying values and meanings. In general it would be better to display the value in a meaningful way, as varying with a specific resolution between a minimum and a maximum value and possibly with specific texts if only specific discreet values are valid. This of course only provides a means of displaying a very specific value and does not provide any indication of the relationship between the actual value and the valid range of values (which would probably best be indicated with some form of slider).

Well, allowing a control to display either a percentage or an angle measurement I think would be easy enough, the difficulty would be in trying to do additional scales like feet, inches, meters, etc.  

Not a real problem. Meters, feet, inches etcetera just need a standard multiplication/division factor, and you'd need an application-wide flag to indicate what unit the user wants, like Poser does in its .INI file. On-the-fly calculation of the value to display from this standard factor and the internal native unit is lightweight, easy and fast.
By the way, fast switching between preferred units and Poser native units (or maybe also FAST native units) would be very helpful for developers - when making ERC code you need to use native units.

Hmm. FaST is going to be pretty much an export dependant project, at least for the first few releases. That being the case, perhaps you might want to look at the major gripes that those who use Poser for figure work for rendering in other apps have. You are addressing a lot of them; one that could be a serious savior if possible is either a plugin or built in function that could reduce the scale of imported skin textures. The 4096x4096 body and facial textures that seem to still be the general default are far too memory intensive when imported into apps like Vue for rendering in a built scene. Being able to drop such a texture set down in increments would let the artist adjust to the minimum needed without having to import into photoshop or gimp or whatever. With an option to save the reduced texture with some kind of simple addition to the filename to identify it as a reduced texture, it would speed the figure setup process considerably...

Quote - The 4096x4096 body and facial textures that seem to still be the general default are far too memory intensive when imported into apps like Vue for rendering in a built scene.

Poser (IIRC) and D|S(certainly) already 'optimizes' texture images (basically downsamples them) to something not-so-bloated when used in preview.

Either way, the RAM used for a given texture image basically shrinks down to a pointer for the original image, and whatever the downsampled image file itself eats (and with OpenGL preview, I think you can offload that half of it to the vidcard's memory... can;t remember offhand though, so that part may not be 100% correct).

/P

Quote - Hmm. FaST is going to be pretty much an export dependant project, at least for the first few releases. That being the case, perhaps you might want to look at the major gripes that those who use Poser for figure work for rendering in other apps have. You are addressing a lot of them; one that could be a serious savior if possible is either a plugin or built in function that could reduce the scale of imported skin textures. The 4096x4096 body and facial textures that seem to still be the general default are far too memory intensive when imported into apps like Vue for rendering in a built scene. Being able to drop such a texture set down in increments would let the artist adjust to the minimum needed without having to import into photoshop or gimp or whatever. With an option to save the reduced texture with some kind of simple addition to the filename to identify it as a reduced texture, it would speed the figure setup process considerably...

Shouldn't present much of a problem really, plenty of C libraries out there in the open source realm that allow you to do easily accomplish such tasks.  What would be helpful though is a list of recommended default settings for such downsampling, provided you have the time.    Since this is something you've apparently had some experience with.

Quote - > Quote - The 4096x4096 body and facial textures that seem to still be the general default are far too memory intensive when imported into apps like Vue for rendering in a built scene.

Poser (IIRC) and D|S(certainly) already 'optimizes' texture images (basically downsamples them) to something not-so-bloated when used in preview.

Either way, the RAM used for a given texture image basically shrinks down to a pointer for the original image, and whatever the downsampled image file itself eats (and with OpenGL preview, I think you can offload that half of it to the vidcard's memory... can;t remember offhand though, so that part may not be 100% correct).

/P

I think the issue here though is when he transports to Vue or another such application that apparently doesn't automatically downsize for previews, if I read the original posting correctly.

I remember starting with Poser 1. I had an immediate use for it then and ultimately expanded on its use in various business projects. Poser has been accused of being a one trick pony for many years and it still around with a large base of support. I don't expect that to change anytime soon. Of course Poser has changed hands more times than a user can be comfortable with and Smith Micro seems the oddest owner of the lot.

With that said, I have no compelling reason to upgrade to Poser Pro. 7 does what I need it to do with DS is quickly becoming more competitive. That doesn't mean Poser is going to die on the vine, it just means Smith Micro is going to have to engineer a purposeful upgrade to get people to part with their money.

To draw parallels I compare Poser 7 to Lightwave 9.
After 13 years I'm moving to XSI as Lightwave is showing its age just like Poser is.
Lightwave and Poser are in a state of a much needed overhaul. But just because many Lightwavers are moving to XSI doesn't mean Lightwave will go the way of the Dodo. So long as both programs can rally their price point while expanding their feature set, they will continue to sell in the hobbyest markets.

Quote - > Quote - > Quote - The 4096x4096 body and facial textures that seem to still be the general default are far too memory intensive when imported into apps like Vue for rendering in a built scene.

Poser (IIRC) and D|S(certainly) already 'optimizes' texture images (basically downsamples them) to something not-so-bloated when used in preview.

Either way, the RAM used for a given texture image basically shrinks down to a pointer for the original image, and whatever the downsampled image file itself eats (and with OpenGL preview, I think you can offload that half of it to the vidcard's memory... can;t remember offhand though, so that part may not be 100% correct).

/P

I think the issue here though is when he transports to Vue or another such application that apparently doesn't automatically downsize for previews, if I read the original posting correctly.

Exactly. Most of the memory issues folks have had with the Vue-Poser workflow have been the 16 megabyte per texture wallop the memory pool takes. The simplest would probably be a 'divide by two' stepping sequence; then you could take a texture down in increments that shouldn't affect the UV mapping. But that only behaves itself when the textures start out in the powers of 2 format to begin with. Oddball sized textures subjected to that can develop noticeable pixellation, or reveal mosaic artifacting at final rendertime, when you subject it to codec compression. And there is no easy way to predict the event happening; its purely a matter of clashing mathmatics. Probably the safest way would be with a divide by two step, a divide by three step, and if the library exists, an option to reduce the color pallete.32 bit textures can be reduced to 16bit, and even 8 bit, depending on the lighting and camera distance. That way you would have a choice of the ways to drop your texture import load without having to deal with another application. Actually, you might want to consider an out and out import conditioning module. Besides texture size, Poser meshes can have issues with backfacing and single sided polygons that Poser either corrects at runtime or ignores....but can bring a mesh import to a sceeching halt with errors. This might be getting too ambitious, but at the very least you'll need to take the cheats Poser uses into account so you don't get caught offguard...

Quote - Exactly. Most of the memory issues folks have had with the Vue-Poser workflow have been the 16 megabyte per texture wallop the memory pool takes. The simplest would probably be a 'divide by two' stepping sequence; then you could take a texture down in increments that shouldn't affect the UV mapping. But that only behaves itself when the textures start out in the powers of 2 format to begin with. Oddball sized textures subjected to that can develop noticeable pixellation, or reveal mosaic artifacting at final rendertime, when you subject it to codec compression. And there is no easy way to predict the event happening; its purely a matter of clashing mathmatics. Probably the safest way would be with a divide by two step, a divide by three step, and if the library exists, an option to reduce the color pallete.32 bit textures can be reduced to 16bit, and even 8 bit, depending on the lighting and camera distance. That way you would have a choice of the ways to drop your texture import load without having to deal with another application. Actually, you might want to consider an out and out import conditioning module. Besides texture size, Poser meshes can have issues with backfacing and single sided polygons that Poser either corrects at runtime or ignores....but can bring a mesh import to a sceeching halt with errors. This might be getting too ambitious, but at the very least you'll need to take the cheats Poser uses into account so you don't get caught offguard...

Well, I don't think it's too ambitiuos overall - in fact I can see this coming in very handy not only for the Vue users but also for animators as well, and particularly for game designers.  Though the initial proposal doesn't mention it since I wasn't planning on this being in the initial release, I do at some point in the future intend on coding a module so that FAST can output characters,  items and animations in a format that those using OGRE as a gaming engine can easily make use of FAST as rapid development tool for game software as well.

That makes the texture reduction/mesh correction features pretty much a must have feature at some point. 

Relevant bits quoted below...

I don't see a way offhand that would give you what you're looking for - a lot of what goes on during transition from one app to the other depends a lot on the app receiving the file. If you replace the called original texture with the downsampled one, your renders will reflect that.

For instance, Vue (during import of a Poser file) calls poser.exe and actually uses it to do the translation of the inbound file. Vue can just as easily have poser.exe call the downsampling functions as it can do them itself. IOW, it all rests on Vue's shoulders as to why it eats the memory hit. If you downsample the images during save (or export), then the .cr2 (being a dumb ASCII file with no facilities to call alternate textures) will either churn errors upon re-entry into Poser, or will simply replace the full textures with the downsampled ones.

There are some conceivable methods to get around this. One would be to custom-tailor the exported file from Poser to Vue (or someone else's) specifications (this could possibly be done with a Python script). Problem is - well, three problems:

1. Once it leaves, it doesn't come back, requiring you to have two versions of the same scene saved (a readable-by-Poser version, and the exported version)

2. You're going to need the filespecs for the app you're exporting it to. This means purchasing an SDK, unless the corp is kind enough to publish them.

3. you now have a shiny set of extra textures that you can't do jack with outside of the program that imports it.

Another method would be to rig the export to a common, open format, like .obj and the like. You end up losing dynamics and other neat-o Poser features, but at least you don't have to buy an SDK license, and you can put whatever you like into the .mtl file. I haven't had the chance to peek at COLLADA, but if it has alternates for preview and render texture pointers, you may have better luck with it.

The best method of all would be to build your own format that includes two calls/lines/specs/whatever for each texture: one for the preview texture, and the other for the real texture. Then make sure it's in the file spec so that any corp doing an import can choose between the two.

As for one piece that needs expounding on:

Quote - This might be getting too ambitious, but at the very least you'll need to take the cheats Poser uses into account so you don't get caught offguard...

Heh - you'll have to do that anyway (evil grin). Merchies are notorious for (not always, but still...) including crap mesh artifacts (e.g. a stray edge-less vert or two sitting 10,000 units away from the mesh but doing not much of anything), infintesimally tiny nGons that comprise Lord-only-knows how many half-edges, the occasional horked face normal, bad vert order, little-to-no optimization, bad welds, and a whole host of things that will make life quite jolly for anyone wanting to write software that reads this stuff.

Quote - > Quote -

I think the issue here though is when he transports to Vue or another such application that apparently doesn't automatically downsize for previews, if I read the original posting correctly.

Exactly. Most of the memory issues folks have had with the Vue-Poser workflow have been the 16 megabyte per texture wallop the memory pool takes. The simplest would probably be a 'divide by two' stepping sequence; then you could take a texture down in increments that shouldn't affect the UV mapping. But that only behaves itself when the textures start out in the powers of 2 format to begin with. Oddball sized textures subjected to that can develop noticeable pixellation, or reveal mosaic artifacting at final rendertime, when you subject it to codec compression. And there is no easy way to predict the event happening; its purely a matter of clashing mathmatics. Probably the safest way would be with a divide by two step, a divide by three step, and if the library exists, an option to reduce the color pallete.32 bit textures can be reduced to 16bit, and even 8 bit, depending on the lighting and camera distance. That way you would have a choice of the ways to drop your texture import load without having to deal with another application. Actually, you might want to consider an out and out import conditioning module. Besides texture size, Poser meshes can have issues with backfacing and single sided polygons that Poser either corrects at runtime or ignores....but can bring a mesh import to a sceeching halt with errors. This might be getting too ambitious, but at the very least you'll need to take the cheats Poser uses into account so you don't get caught offguard...

What I'm considering here, Peng, is if FaST works as RD is intending, then Poser content moved into FaST would most likely adopt an internal runtime structure that would be optimized for FaST. If that were the case, then dynamics would be the province of the FaST modules, not Poser's. If E-on and SM can get the SDK issues between Poser and Vue hammered out once and for all, great. As it stands now, I'm leaning more and more towards untextured or minimally textured Poser exports with same being done with SkinVue. What I'm -hoping- is that the FaST project provides more modern dynamics and strand based hair for animating, and an animation suite that includes some of the goodies we've been asking for for years. If it can do that and export it in a poser-readable format (or a format close enough to Poser's that those external proggies can read it), I'd likely retire Poser as my figure animation app (or if Modo gets better animation controls, hair and cloth, and the beta Poser import app that Opera mentioned works as hoped, then it would be Modo....with lots of nudges to get it talking to Vue Infinite as well). There isn't a whole hell of a lot left to do regarding Poser and single pose figures (except better lighting). Animation is the growth area, the one that needs the most attention. Oh, and you forgot the lonely bone off to the side that sends the import app into apoplexy in the dirty little secrets list.... :P

Quote - What I'm considering here, Peng, is if FaST works as RD is intending, then Poser content moved into FaST would most likely adopt an internal runtime structure that would be optimized for FaST. If that were the case, then dynamics would be the province of the FaST modules, not Poser's. If E-on and SM can get the SDK issues between Poser and Vue hammered out once and for all, great. As it stands now, I'm leaning more and more towards untextured or minimally textured Poser exports with same being done with SkinVue. What I'm -hoping- is that the FaST project provides more modern dynamics and strand based hair for animating, and an animation suite that includes some of the goodies we've been asking for for years. If it can do that and export it in a poser-readable format (or a format close enough to Poser's that those external proggies can read it), I'd likely retire Poser as my figure animation app (or if Modo gets better animation controls, hair and cloth, and the beta Poser import app that Opera mentioned works as hoped, then it would be Modo....with lots of nudges to get it talking to Vue Infinite as well). There isn't a whole hell of a lot left to do regarding Poser and single pose figures (except better lighting). Animation is the growth area, the one that needs the most attention. Oh, and you forgot the lonely bone off to the side that sends the import app into apoplexy in the dirty little secrets list.... :P

My plan is to support Posers original runtime structure and file format, however FAST will also have it's own native file formats that you can convert to should you decide at some point to replace Poser entirely.

The reason for this is that Posers file format does not support some of the features I'd like to include - so the FAST specification will have some things in it's file format that Poser file format just wouldn't understand.

However I plan to make it "backward" compatible with Poser's runtime structure so that you can still run Poser and FAST side by side, should you so choose.  Vue compatibility, however, might be a bit rougher.

If view understands a file format that is well documented, like collada, that will help.  However after reading throught the above postings I see something else I hadn't considered, how do you get view to switch from the preview textures to the full textures when it comes time to render?

In essence what you would need to do is export from FAST, import into vue, do what you need to do with vue and then export the new information back to FAST again and allow FAST to do the rendering.

Either that or perhaps an external utility, one that rewrites the references in the FAST exported file from the preview textures to the full textures, but again you'd be looking at having to save the VUE file into a file format that could be understood by the utility, run the utility, then reload into vue to make this work, assuming Vue doesn't have some of internal scripting language that would allow you to switch textures on the fly - I don't own a copy of Vue so I'll have to see what I can come up with, but again not something that has a huge priority at least for the intial release.

Eventually I'd like FAST to evolve into an entire set of tools not just for still renders but for animations as well, tools that allow you to sync an audio layer and automate a characters facial movements, for example.    The final goal will be to make it so you can setup an animation quickly and easily, render it (in background, over a network, or even to a cluster of machines if you so desire), add in any other portions of an audio layer you'd like, sync it to the video, and output the final video in standard formats like mpeg and possibly even .swf or other formats for web or game programming venues.

A lot of the external tools that are now available, like software to alter your voice, are things I'd like ot make as add on modules for FAST, so that it becomes more or less the only tool you need to do such animations.

I'd also at some point like to integrate a lot of the "gimp" code into fast, giving you the ability to composite and edit still pictures, do things like comic book pages quickly and easily, output them to either picture format, html or even PDF if you desire.  And at some point I'd really love to give fast the abiity for you to texture 3d items in 3d - painting on them directly so you can see exactly what your doing quickly and easily.

Ok, now granted a lot of these capabilities are going to be much further down the road than the initial development, and all will be available as "plug in" modules so if it's not a tool you need or want you don't need to take up drive space for it.  But these are just a few of the ideas I have in mind for further development of FAST, once it's past it's initial release phase.

All in all I know it's a pretty ambitious project, but doable - a lot of these features already exist in other open source programs, it's just a matter of coding something with a decent interface and putting it all together in one suite of tools that are user friendly and designed to work with one another, so hopefully at some point the days of importing one file format to a program so you can do this feature and then exporting to another to do that feature will be a thing of the past.

No gaurantees, of course, but that is the eventual goal I'd like to accomplish with FAST.

Quote - What I'm -hoping- is that the FaST project provides more modern dynamics and strand based hair for animating, and an animation suite that includes some of the goodies we've been asking for for years.

Give me a wish list - no promises on when or if they will all get implemented, but I'll see what I can do.

GIMP/GTK? Heh - you ARE a masochist, aren't you? :)

(kidding! Err, almost.)

Yeah - the whole texture switcheroo thing is what I was getting at as a major obstacle. You get one or the other, but not both... and no app alive can make another app do both (at least not without an SDK and a metric shedload of exposed goodies in it to facilitate such things).

ROTFL... Dale! You bastard -I forgot all about the invisible mystery bone! :)  I guess I hadn't seen one in so long... 

I agree that FaST couldn't hurt to have its own file format. Then again, hell - FBX and COLLADA are open, and they both have very generous specs as to what kinds of stuff you can store in them. D|S originally built the .daz binary format because 1) .obj is too limited, 2) .3ds sucks to write for (in addition to being almost as limited as .obj), and 3) there wasn't really anything else at the time that filled the bill, unless you wanted to pay some corp a ton o' cash for the privilege of writing to theirs. But... back on the first hand: with your own format, it's hella easy to read-in and write-out your own files, your way. Call it sixes?

Renderdog... a LOT of what you're describing is already present in D|S (insofar as Poser compatibility), but they stopped well short of direct export of .pz3 files outside of testing- and I haven't seen anything reliable come of anything in that direction last I checked (this may have changed, but I'm not holding my breath). Pose, Char, Lights, files like that... no prob. But strangely enough,  .pz3 (the entire self-contained scene-in-a-bucket) is a royal screamer to construct - at least in a manner that can be consistently read-in to Poser. That is, unless you use Poser itself to write it. I wish I knew why that is.

/P

Quote - GIMP/GTK? Heh - you ARE a masochist, aren't you? :)

(kidding! Err, almost.)

Yeah - the whole texture switcheroo thing is what I was getting at as a major obstacle. You get one or the other, but not both... and no app alive can make another app do both (at least not without an SDK and a metric shedload of exposed goodies in it to facilitate such things).

ROTFL... Dale! You bastard -I forgot all about the invisible mystery bone! :)  I guess I hadn't seen one in so long... 

I agree that FaST couldn't hurt to have its own file format. Then again, hell - FBX and COLLADA are open, and they both have very generous specs as to what kinds of stuff you can store in them. D|S originally built the .daz binary format because 1) .obj is too limited, 2) .3ds sucks to write for (in addition to being almost as limited as .obj), and 3) there wasn't really anything else at the time that filled the bill, unless you wanted to pay some corp a ton o' cash for the privilege of writing to theirs. But... back on the first hand: with your own format, it's hella easy to read-in and write-out your own files, your way. Call it sixes?

Renderdog... a LOT of what you're describing is already present in D|S (insofar as Poser compatibility), but they stopped well short of direct export of .pz3 files outside of testing- and I haven't seen anything reliable come of anything in that direction last I checked (this may have changed, but I'm not holding my breath). Pose, Char, Lights, files like that... no prob. But strangely enough,  .pz3 (the entire self-contained scene-in-a-bucket) is a royal screamer to construct - at least in a manner that can be consistently read-in to Poser. That is, unless you use Poser itself to write it. I wish I knew why that is.

/P

Lol.. actually I'm a lot more comfortable with GTK than I am with QT, in fact so far QT is presenting a host of issues that may well cause me to reconsider using it.  While I've worked with the professional commercial version, the open source version seems pretty limited by comparison.  So this might just become a GTK app from the ground up.

As to it's own file format, there are some things i'd like to be able to do that I'm not certain any other file format would take into account.  For example, in Poser you can use the grouping tool to multigroup faces - however when you do the tool is still limited to only those areas defined by bones.

There really is no valid reason for this, yes you do need one set of groups to define mesh areas for the figure for bones, however you should be able to do an entirely different set of mesh areas for materials.  While this gets kludged together in Poser, I intend to keep it seperated in FAST.

Actually I was thinking of going one better, I'm still reading up on some basic bone theory, however it occurs to me that you should be able to have two (or even more) entirely seperate sets of bones with different mesh groups for different purposes.  Take a skirt, for example.  one set of bones could be used to conform it to the figure, an entirely seperate set of bones could be used to move, bend and twist the mesh in various ways to fit the skirt properly for various poses.  There is no reason why these two sets of bones need to be connected to one another, in fact they could very well be processed seperately by the program and still work just as well.  It would certainly make rigging a lot easier if you had one set of bones for conforming purposes, and those bones were hidden from view and not considered when you started working with a seperate set for posting purposes.

I'm still reading through the collada format, if I can accomodate everything i'd like to do in collada I'd love to make that the native file format, but as it is I'm not certain that will be the case, so jury is still out there.

As to Daz Studio, it does have some nice capabilites, don't get me wrong, but it's not a Linux App and in order to get a lot of the functionality I'd like to have I'm stuck buying mondo plugins for it.  That's all well and good, I have nothing against throwing a few bucks towards the coders for there work.

But aside from the fact that it's not a native linux app, the problem comes in when they upgrade from one version to another.  Each time they upgrade there is a chance that whatever code changes they make will "break" the plugin your using, so you have to upgrade your plugin.  Now, what happens if the author for that particular plugin abandons it and doesn't upgrade for the new version?

This of course is just one of the difficulties I see with DS, that and in all honesty I really dislike the interface, and it suffers from one of the same major drawbacks that poser does, it's rendering engine is just nothing to sneeze at.

So after really considering all the options I thought an open source replacement was the way to go, and there are so many possibilities out there for additional features it's not even funny. 

I am following this thread with an all-consuming passion, and am incredibly excited by the ideas that are being presented. My own programming ability is limited to VBA (Excel) and (remotely) Foxpro, so I can't say I really understand the development issues of QT (which I understand D|S is written in) vs GTK (The GIMP?)... but since I'm a heavy user of the GIMP and Blender3D and Ubuntu Linux and an avid advocate of the Open Source movement, I applaud the insistence on at least dual OS development... and the underlying philosophy driving this.

I run WindowsXP at this point almost exclusively for Poser 7 - I did try to run Poser in WINE, but the interface issues became too irritating, so I went back to WinXP for Poser. I never get on the Internet in Windows, and do everything non-Poser in Linux. The people at Silo are seeing the handwriting on the wall and are creating a Linux version. This will be the first - and by your proposed ideas - the most comprehensive posing/modeling?/animation/rendering application for any OS out there, and the only one of its kind for Linux. You have my undying, enthusiastic support, RD! If there is anything I can do to help.... I'm here!

Plugins that break when a newer version of the base app is released.
Yup, that's a major pain in various body parts. Preventing it from happening is quite hard to do, but at the very minimum it requires a very wel thought out set of APIs for the base app THAT DOES NOT CHANGE WITH EACH VERSION. And if new functionality is incorporated into the base app, a new API should be added to the existing one(s), in order not to break existing apps that use the older API.
It's not unlike the infamous COM DLL Hell. I've programmed COM components and it can be done right, but that requires self discipline on the part of the developer. You have to stick to the COM versioning rules, and there's nothing in the development enviroment that prevents you from deviating from those rules.
Microsoft itself breaks its own COM versioning rules on a regular basis (ADO2.1 apps break when ADO2.5 gets installed, which should not have happened). Can be very frustrating.

The only way to make an app stable for plugins is by freezing APIs. A new set of APIs would mean a new major version number, minor version upgrades should not change existing APIs. 
Even better, a new major version would/could have new APIs in addition to the unchanged existing ones from the previous versino, so that plugins written for FAST 1.x would still work in 2.x and up.

I like the Linux version numbering system: odd minor release numbers are "test" releases, that introduce new functionality, even numbered minor releases are stable releases. Revision numbers and build numbers would be reserved for fixes/patches. It's a well known system, and as such it would make it easier for users to understand the FAST versioning scheme.

Quote - I am following this thread with an all-consuming passion, and am incredibly excited by the ideas that are being presented. My own programming ability is limited to VBA (Excel) and (remotely) Foxpro, so I can't say I really understand the development issues of QT (which I understand D|S is written in) vs GTK (The GIMP?)... but since I'm a heavy user of the GIMP and Blender3D and Ubuntu Linux and an avid advocate of the Open Source movement, I applaud the insistence on at least dual OS development... and the underlying philosophy driving this.

I run WindowsXP at this point almost exclusively for Poser 7 - I did try to run Poser in WINE, but the interface issues became too irritating, so I went back to WinXP for Poser. I never get on the Internet in Windows, and do everything non-Poser in Linux. The people at Silo are seeing the handwriting on the wall and are creating a Linux version. This will be the first - and by your proposed ideas - the most comprehensive posing/modeling?/animation/rendering application for any OS out there, and the only one of its kind for Linux. You have my undying, enthusiastic support, RD! If there is anything I can do to help.... I'm here!

Lol.. well, it will be an ongoing project to be certain, but I'm pretty confident that once we get an alpha release and a bit of a following the developer base will expand quickly, allowing us to hopefully start implementing a lot of these features in the first few versions.

It's going to be an interesting project, that's for certain - most newer modelers and the higher end CGI shops use sub division modeling on lower poly meshes with a combination of high end maps to produce the sort of quality images you see in there work.

Poser, on the other hand, uses a much higher poly mesh and much less in the way of shaders/displacement maps.  So one of the big challenges will be to support the Poser way of doing things and yet still provide the higher end, sub-d type structure that most high end CGI operations use.  I think I've got a plan worked out there, in fact it will be a "selectable" flag on each object as to whether or not it uses sub-d, it will be applied as needed to each object in the scene.

A few other hurdles to be overcome of course, GTK offers much better and easier to use GUI builders in the open source area but they are not Mac compatible, at least not yet.  While they are working on a Mac port, it's not 100% ready for prime time.

So if I use GTK that speeds up development for Linux and Windows, but slows it down for the Mac, as I will either have to code a seperate interface for Mac or what until GTK ports to mac so it can run on there systems.

Qt would alleviate this, but there open source gui editor.. wow, ick doesn't even begin to cover it.  They strippd out about 95% of the functionality compared to the commercial version, and really it's only slightly better than building the GUI by hand from what I can see, so I'm really leaning away from QT.

There are other open source alternatives of course, but none that really have the maturity or the types of widgets necessary to build an application of this nature.  So I'll give it some more thought and see what I think the best final solution will be, but it's looking more and more like this will be a GTK app.

Quote - Yup, that's a major pain in various body parts. Preventing it from happening is quite hard to do, but at the very minimum it requires a very wel thought out set of APIs for the base app THAT DOES NOT CHANGE WITH EACH VERSION. And if new functionality is incorporated into the base app, a new API should be added to the existing one(s), in order not to break existing apps that use the older API.

It's not unlike the infamous COM DLL Hell. I've programmed COM components and it can be done right, but that requires self discipline on the part of the developer. You have to stick to the COM versioning rules, and there's nothing in the development enviroment that prevents you from deviating from those rules.

Ya, that plugin thing can be a real double edged sword, no doubt about it.  Now if you paid for the program and the plugins were free, then it probably wouldn't be nearly as much as an issue.  But as it is since the program is free and the plugins are all maintained by different developers, it's a real mixed bag as to what happens whent they upgrade.

Each new version runs the risk of breaking the old plugins, and every developer then has to update there plugin.  In the interim the user has no idea how long that will take, how well it will work, or how much it will cost for him to buy the upgraded plugin once it's available. 

This is one of the main reasons why I've steered clear of D|S, I disliked the interface at first glance, and I wasn't about to waste a lot of time getting comfortable with it under those circumstances. :)

The onus of not breaking older plugins is on the base app. Here's what I mean:
For example, you expose a Geometry object through an API. In the first version of FAST, subdivision is not supported, so the Geometry object doesn't have a SubdivisionLevel property.

Say, plugin X makes use of the Geometry API, and it works just fine.

THen the next version of FAST is released, this time with subdivision. You'd want to expose this new functionality through an API again. Well, if you change the Geometry API to include a SubdivisionLevel property, plugin X won't work anymore! The new Geometry interface is different from what it expected.

Solution: keep the old Geometry interface, and create a new Geometry2.0 interface that incorporates everything from the old interface and adds new properties and methods.

The risk, of course, is API bloat. But as far as I know, it's the only way of maintaining compatibility with existing plugins.
When releasing a new major version, you could opt to scrap the older interfaces. Older plugins won't work anymore, but then again, I don't expect a plugin that was written for version 1.0 to still work in version 4.0, for example. Backwards compatibility should only go so far.

Clearly, D|S doesn't work this way, else the "broken plugin" problem wouldn't be so ubiquitous. There seems to be no backwards compatibility at all.

Quote - The onus of not breaking older plugins is on the base app. Here's what I mean:
For example, you expose a Geometry object through an API. In the first version of FAST, subdivision is not supported, so the Geometry object doesn't have a SubdivisionLevel property.

I agree wholeheartedly, but it seems as if Daz seems to be taking slightly different take on it, in that they seem to break backward compatibility from the old to the new API whenever it suits them and the plugin writers can either do what they have to do to compensate or their plugin can stay broken, Daz doesn't appear to care much either way, at least on the surface of things.

This is probably one of the biggest reasons I've stayed away from Daz studio, I don't want to be investing a bunch of money in plugins only to find out that they are not supported by a new version, even worse to find out that the developer has decided to double,triple or quadruple his price with no upgraded pricing available for the new version of his plugin to the new version of D|S.

Being that dependent on that many different parties, and being subject to the whims of so many different developers - well, just not my cup of tea. 

There is ONLY one reason that I've downloaded Daz Studio, -to create Collada files from Poser Pz3's to open in Max.  Finally I've got a Posette and Judy that are boned and Posable in Max, and without the visable seams between body parts that I had with Pomax.  So, as far as I'm concerned, DS does have a definite, but limited use. 

Other than that, I can see any use for it whatsoever, -none of my imported Poser content seems to come with any visible morph dials.  Nor do I see any easy way to keyframe animation, -and since I don't like the default Victoria 4, I guess I'll stick to Poser and Max.
DPH

Quote -
Lol.. actually I'm a lot more comfortable with GTK than I am with QT, in fact so far QT is presenting a host of issues that may well cause me to reconsider using it.  While I've worked with the professional commercial version, the open source version seems pretty limited by comparison.  So this might just become a GTK app from the ground up.

Depends on where you d/load it... I don't much bother with Qt Designer except for mock-ups (mostly to check spatials and arrangements). Otherwise, I use my own bitmaps and color schemes, and edit the bastich in a real IDE (Used to be a SlickEdit addict, now I just stick with Eclipse.)

Quote - As to it's own file format, there are some things i'd like to be able to do that I'm not certain any other file format would take into account.

True enough. It also limits your featureset to what the format spec can provide.

Quote - Take a skirt, for example.  one set of bones could be used to conform it to the figure, an entirely seperate set of bones could be used to move, bend and twist the mesh in various ways to fit the skirt properly for various poses.

I love the idea of having two sets of 'bones'... I'd been toying with the idea offhand for awhile now (that is, one set of invisible joint-matching bones and 'skeletal' mesh to conform an item to the figure, and a second set of visible bones in a parallel hierarchical tree/branch set to allow for clothing movements). This allows for more accurate clothing movements (e.g. a jacket that actually drapes backwards at the bottom when a figure sits down, long skirts that can actually drape outwards away from a figure's sitting butt and legs, etc.)

Material zones are a different critter altogether. in D|S they are (IIRC, have to check) treated separately.

Quote - I'm still reading through the collada format, if I can accomodate everything i'd like to do in collada I'd love to make that the native file format, but as it is I'm not certain that will be the case, so jury is still out there.

It's possible, but that depends on the features you want to include. OTOH, you could possibly extend it as well, then have one export save to the std. COLLADA format for everyone else, and your own extended version for in-app goodies. Whether other apps decide to use those extensions or not is up to them... who knows, maybe COLLADA will decide to add the extensions? :)

Quote - As to Daz Studio, it does have some nice capabilites, don't get me wrong, but it's not a Linux App and in order to get a lot of the functionality I'd like to have I'm stuck buying mondo plugins for it.  That's all well and good, I have nothing against throwing a few bucks towards the coders for there work.

No worries - that's how it's built. The codebase can (at least since OSX/Intel) be hammered into working natively with Linux, but that'll take some convincing of the PTB there. The biggest job there would be converting the libraries (preferably to static 2.6 kernel-friendly libs to make it more or less universal). But... since that doesn't seem like it's gonna happen anytime soon, hey - go for it. I'd be happy to help when and where I can.

Quote -
So after really considering all the options I thought an open source replacement was the way to go, and there are so many possibilities out there for additional features it's not even funny. 

Indeed - and I for one would love to see it happen. :)

/P

Quote - [Depends on where you d/load it... I don't much bother with Qt Designer except for mock-ups (mostly to check spatials and arrangements). Otherwise, I use my own bitmaps and color schemes, and edit the bastich in a real IDE (Used to be a SlickEdit addict, now I just stick with Eclipse.)

Haven't worked with eclipse much myself, but after perusing it looks like it has some really nice features.  Might have to give it a whirl.  Been a while since I did any Linux coding, most of what I've been doing lately has been Visual C, so this will be a very nice change of pace.

Quote - I love the idea of having two sets of 'bones'... I'd been toying with the idea offhand for awhile now (that is, one set of invisible joint-matching bones and 'skeletal' mesh to conform an item to the figure, and a second set of visible bones in a parallel hierarchical tree/branch set to allow for clothing movements). This allows for more accurate clothing movements (e.g. a jacket that actually drapes backwards at the bottom when a figure sits down, long skirts that can actually drape outwards away from a figure's sitting butt and legs, etc.)

Material zones are a different critter altogether. in D|S they are (IIRC, have to check) treated separately.

One of my biggest problems with poser has always been that material zones in Poser are edited with the same grouping tool you use to group parts of the mesh for rigging, which works fine, if you setup your material zones before you add bones.  If you don't, well it becomes a royal pain in the butt.  It also becomes a real pain when you want to remove a material zone you setup but realize you don't really need or one that was imported as part of the original object but you don't want - the only way I've found to get rid of such a "orphaned zone" is to go in and hack the cr2 with a text editor. 

My own plan is a little different, if I can get it to work right you'll be able to do multiple bone sets and the material zones will be considered seperately as well, so you can slice and dice the mesh pretty much as many different ways as you need to get the desired effect.

Quote - It's possible, but that depends on the features you want to include. OTOH, you could possibly extend it as well, then have one export save to the std. COLLADA format for everyone else, and your own extended version for in-app goodies. Whether other apps decide to use those extensions or not is up to them... who knows, maybe COLLADA will decide to add the extensions? :)

I like the idea of extending collada and making the format changes openly available to other developers.  Some of the features I'm thinking of probably won't be supported entirely by the original.  For example, an flag in the character/prop file to indicate that the mesh was intended to be used with sub-d modeling.  That way FAST can apply sub-d to objects either in preview mode or when they are submitted to render based on this flag.  Lower resolution items could then be used to much greater effect, and speed could be increased dramatically. 

For high end, complicated meshes like V4, this flag would default to off - so sub-d would not be applied.  More or less a smart filtering system for what objects need sub-d and when it should be applied.  Naturally the end user will be able to overide sub-d on any object merely by adding or removing a checkmark from that box, but this way merchants and content providers can setup objects to use sub-d by default, and if the end user doesn't change this default setting (which most will not) they'll never really know the difference between that and a much higher poly mesh, other than of course when they go to render or animate and the speed difference becomes apparent.

In this way I think it will be possible to remain true to Posers traditional higher poly meshes and still be able to integrate them with the more industry standard lower-poly mesh with sub-d applied and make it as seamless as possible for the end user.

Lol - needless to say I have my work cut out for me, but were off to a promising start so far and I'm pretty confident that once I get something I can release as pre-alpha over at sourceforge it will be enough to show other developers that the project is viable, and we'll be able to recruit a few prior to the actual alpha stage.

Once we get past the alpha stage I have a feeling we'll be getting more than a few developers signing on, I think this will be the sort of project that will really grow quickly over time.

An inbuilt application UVW mapping tool might also be a good thing, similar to Max's UVunrap modifier that lets one to map an object while modeling it.  One could supposedly then take figures mapped to one configuration, such as Vicky 2 and remap her to take V3 textures and thus do away with the need for texture converters.
DPH

How about image map, procedural, and gradient options for surfacing.  Layer support as well.

The only reason I even touch DS is to get my Poser Contenet into Bryce for Animations and since I haven't done an animation in almost a year, DS is just taking up space on my HD.

In case you are interested, Vue uses python for scripting - I don't know the details but asking in the Vue forum here (or the scripting forum at Cornucopia3D)  might get you some decent answers.

Poser has two long-tunning ptoblems, and no new owner has ever fixed them. 1] Poor Documentation: go look at the section in the manual describing materials nodes. If your're not educated as a computer graphics professional, it's almost useless. That's only one example. 2] User interface preferences: Poser ignores Windows settings for colours and font sizes, except for its idiosyncratic use of standard Windows windows. I'd like to be able to set a slightly bigger font, and use background/font colours which give better contrast for my vision. You shouldn't need to hack at XML files to do this. Though I suspect we'd have to rip out pretty well all of the existing code for the UI. There are some things which appear to be unalterable parts of graphics files. This inability to tweak the system may even be illegal under current disability laws.

You can alter the png's in the UI folder and change the interface, but you have to screw with the xml files for the font. Effectively you could redesign the look pretty easy, but here again only so much without altering the xml files. They put the UI folder in the Runtime folder. Isn't that where you can also put 3rd party content? Why illegal?

dogor,

Quote - This inability to tweak the system may even be illegal under current disability laws.

You can tweak it somewhat (as mentioned elsewhere), but I sincerely doubt that it falls under any sort of ADA violations. I doubt that even the numerous shortcomings of Windows in disability accommodation  would constitute one.

Quote - *Patorak wrote:

• Need original figures for your app?  I'm not talkin' icky Vicky characters or hollow Apollo characters but original figures.

coughs Gotta love that wonderful community spirit among user figure makers; with ryhmes even. What ryhmes with Jane and is equally dismissive of effort and quality? Nah, that would just be lame.

I thought we were unanimous in recognising that apollo was the best male figure yet
released for poser.

anyway, my apologies for the bad documentation of the last few poser versions.  unfortunately
it's not the coders who write the manuals, and it's very difficult for tech writers to get the coders
to tell 'em enuff details to write it the way we'd like.  however, that's where these various
websites (here, daz, rdna et al.) become valuable.  there are quite a few users who can fill
in all the gaps and explain it to the rest of us, hence the lack of details in the manual is no
longer so problematic.

Quote - "Patorak wrote:
Need original figures for your app?  I'm not talkin' icky Vicky characters or hollow Apollo characters but original figures."

coughs Gotta love that wonderful community spirit among user figure makers; with ryhmes even. What ryhmes with Jane and is equally dismissive of effort and quality? Nah, that would just be lame.

ahahahahaha...snort!...AHAHAHAHAHA!  Stop it!  You're killin' me!