VirtualWorldDynamics opened this issue on Jun 14, 2015 ยท 787 posts
Morkonan posted Sun, 05 July 2015 at 11:35 PM
@ Morkonan : I'm not an expert on hair in Poser, but I feel that there is a global need to find a realistic approach to creating, texturing, and positioning for virtual 3D hair. I would be very interested by your advice in your positioning and animation with VWD, I think the result is good enough. There remains the problem of creation. In this area, I would separate the generation that I guess by wire from the mesh generation that can be of different shapes.
I think that once again, the dynamics can be useful for the generation; by cons, the generation is a pure IT problem.
After launching the program, it might be worth to open a thread on this topic. What do you think?From time to time it is good to relax by playing with ribbons for example. You can see the result on YouTube. Tell me what you think.
My wife does not like too bright colors. I agree that the colors are not very pretty, they are there only to show the absence of interpenetration. I could redo the video with textures if you wish. ;-))
I think that any thread which continues technical discussions dealing with your product and dynamics working with Poser would be a very good thread! :) I took another look at your early videos, just to see what I could of how many variables can be used in your calculations. You've really covered a great deal! And, that simulations are highly customizable is an added bonus, providing many of the customizable settings in Poser's Cloth Room with your wonderful new engine.
However, of critical importance is longevity. As you noted concerning Weirdjuice's python-based dynamic fluid simulator, there is always the danger that a product made for Poser can be easily orphaned. Changing Python versions is just one of the issues.
There are things about Poser that are starting to be overshadowed by companion products. For instance, Reality4, with the upcoming speed-boosting patch, is likely going to be a Firefly rendering-engine "killer." Why render in Firefly if you can render using a physics based renderer that will render more accurately, more realistically, and, soon, in half the time to achieve even better quality than what Poser's native Firefly can do?
Your product, because of its sheer versatility and ability to handle multi-grouped objects with ease, even very complex ones, like polygon-based hair models, will likely outcompete Poser's native dynamics engine, overnight, based only on its speed, if nothing else.
There are others who have introduced products that move animation/object assets out of Poser's native interface in order to take advantage of new tech and new developments. For instance, DAZ3D's "Genesis" figures and .duf format is a format standard that is brought into Poser and competes with Poser's .cr2 file format. (Purposefully, and not very well, but it's still a competing standard produced by a third-party.)
What I'm getting at is this - There are two things to consider in terms of "longevity."
What dependencies must you absolutely rely upon and how can you secure them through any changes Smith Micro might reasonably make? Poser's .cr2 file structure isn't going anywhere, soon, and they'd probably make allowances for any format changes in order to accommodate legacy products. But, in order to give your product the best chance at along saleable lifetime, you may wish to consider ways to work with other formats. And, that also opens up the possibility that your product could be used... industry-wide, as a quick tool to provide visualizations, animation demonstrations, blocking-in movie shots, a whole gambit of possibilities... In other words, ensuring your product's longevity through Poser production cycles by structuring what sorts of data it can take and what file types it can work with could result in a very robust product with a much wider scope than just us. (Though, I eagerly look forward to being able to buy it for Poser content! :) )
The other thing to consider is constant third-party competition with Poser, both in the areas I mentioned by those producing add-on products for Poser and those producing directly competing products. Considering the performance of your product and its visual appeal and polish, I would suggest you may want to actually talk to Smith Micro regarding their dynamic engine and the possibility that they might wish to license a portion of yours for their own use. Poser has done that before and I wouldn't doubt they could do it again. You could, of course, retain full release rights for an engine, for instance, that worked with many other file types in the industry or one that was specifically targeted towards certain development pipelines. And, if Smith Micro doesn't wish to do that, there's always DAZ3D. They seem to retain the competitive "hunger" that many successful companies hold on to regardless of their market shares..
Flexibility is key and the ability to work with different data sets, even if you don't include that ability at first, can really be a value-added part of your product and could really expand its possibilities outside of just Poser.
markdc, a vendor here, has produced a number of outstanding products. I'll point to one of his as an example - Autogroup Editor. It's a very simple group editor for wavefront.obj files. However, it is not wholly dependent upon anything in Poser. It runs outside of it and, while it can accept .cr2 files, it can also accept any wavefront.obj file. In essence, you don't have to have Poser in order to make that product useful! Sure, you'd probably have access to 3D software that did all that for you, but I use it very often on just .obj files to set up groups quickly and easily. I never use it with .cr2 files.. I have no need to use it like that since I'm creating the .obj myself. But, instead of limiting his product to only .cr2 files, as some have done with other products, markdc allowed .obj files to be loaded as the template objects. Sure, it probably wasn't difficult to do, but the world is full of tragedies that could have been avoided if the participants had one just done one little thing that wasn't particularly difficult to do at the time. :)
I'm not saying to focus heavily, yet, on uses other than for Poser. But, I am saying that you should consider it, just to help give your product longevity and versatility. And, you never know where Smith Micro is going to go next. Right now, assets for game development are really high on their charts. That's great! And, you should be prepared to be able to move along that direction as well as others.
Again, great product, wonderful speed, good versatility already, from what I can see. I just don't ever want to see your product orphaned by a python switch. :)