Quote - There's another thread going on currently about the future of  "content" figures.  It's largely a discussion of advantanced and klugey rigging techniques and how long it will be feasible to support both the Daz and Poser markets with the same characters.

There is a clip in the video I linked to above where a figure is posed simply by grabbing and dragging the hands and feet.  The neat thing is that this is not a rigged figure, but a solid mesh.  They are using a custom solver to somehow discern (via body mass?) how this character should bend.  It's not a totally realistic effect, as the character ends up moving like a rubber figurine, but at least to the eye it looks good, especially with the mo-cap data applied.

This got me thinking that the future really isn't in the figures, but in the rigging itself.  Mesh resolution and rigging are the two areas where the most attention has been paid to commercial figures, and with each new one comes the need to build or buy complementing accessories.

So, my idea is similar to zBrush modeling rigs.  I'm thinking of a kind of default rigged bipedal cage.  It has the proportions of a basic human, and has been rigged down to the hands and feet, perhaps even to the fingers and toes.  What it would do is let you import a figure of your own creation, say from makehuman or zBrush, and then adjust the cage until it fits the imported mesh.  Then the mesh could be bound ot the cage and a new figure would exist, able to share any pose or motion created for the pose rig.  Muscle deformers could be linked to the pose rig and would available for any future figure created.  Of course changing the size and proportion of the pose rig would affect its poses.  (Perhaps a special-case use of IK could try to make sure that hands and feet stay in the same absolute locations, as they are the parts most likely to be in the wrong place when using one figure's poses with another.)  A more advanced solution could perhaps try to make sure parts didn't intersect, say when a pose for a skinny figure is applied to an obese one.  Also, shouldn't it be much easier to transfer facial poses from one figure to another than it currently is?  Why can't I just line up the new figure with the old one and have the software create corresponding morph deltas?  Maybe someday makehuman will be able to let me match the default figure's proportions to an imported mesh, then transfer a pose from the default figure to the imported mesh?  It'd be a start, like conforming in reverse almost.

I'm sure most of this is off topic.  But as I keep coming across threads prediciting the end of Poser, I can't help but think that it's the figure business causing the problem.  There might not be a way to make rigging automatic, but for a basic human figure it shouldn't need to be done from scratch every single time.

I have never really done any figure rigging (outside effects props.. simply for ease of use to end users), but can't rigging be simply done in Poser with a donor figure? I mean, I realize that tweaking would certainly be necessary, but I think you can borrow a skellie from a similar figure as to your own creation (bi-ped, quadraped, etc) and apply it. Maybe I stand to be corrected, but I think it can be done this way. But that's Poser. I don't know if the rigging can then be exported outside Poser for other apps without a 3rd party app. Figure/character rigging is certainly not my area of expertise ;o)

Quote - > Quote - Personally I think SM has about 18 months to produce the next version of Poser and they better include a lot of new features (like a completely 64 bit version...

I do believe that they have a version already that is 64 bit. Also , we must remember that Poser 4 was out for many years before Poser 5 came along and it was still extremely popular (meaning P4) when Poser 6 came along ;o)

Ok it isn't completely 64 bit I guess, but these are Poser Pro's key features taken from Smith Micro's web site:
Key Features:

• 64-bit Render Engine
  Poser Pro users will benefit from the network rendering and render queue capabilities, including background rendering, built on a 64-Bit render engine for incredible speed and quality!
• HDRI Export
  Poser Pro creates even more realistic images with High Dynamic Range Image (HDRI) support for Image-Based-Lighting and textures.
• Normal Map Support
  Poser Pro allows you to add high resolution 3D detail to any mesh through the use of normal mapping, producing better images, even with low to medium poly models.
• Hosting with PoserFusion™
  Realize the added benefit of using Poser Pro's pre-rigged characters inside of host applications such as Autodesk's 3ds Max and Maya®, and Maxon's CINEMA 4D®.
• Network Rendering
  Get the most out of your hardware and leverage your network to render massive scenes using the network render queue.
• Professional Content
  Create lifelike animations by combining multiple strands of action into one fluid animation using layers. Keyframes automate between poses.

Quote - Personally I think SM has about 18 months to produce the next version of Poser and they better include a lot of new features (like a completely 64 bit version...

I do believe that they have a version already that is 64 bit. Also , we must remember that Poser 4 was out for many years before Poser 5 came along and it was still extremely popular (meaning P4) when Poser 6 came along ;o)

Quote - The cause of this behavior is the fact that Poser objects are very, very small. Try importing a Poser .OBJ directly into another 3D app - it'll be extremely small. For example, when I import into 3DS Max, I scale up by a factor of 250, so a human figure will be about 6 feet tall in the Max universe.
Firefly is not a render engine developed by Curious Labs, its origins are 3rd party (used to be called Vortex, as far as I remember). So it's not surprising it was not built from the ground up to render these extremely small objects.
I'd say it is a fundamental flaw in Poser, not a Firefly bug.

I see. I didn't realize it was 3rd party. Yeah it would be a Poser flaw ;o)

Yeah I often scale up in Rhino by a factor of 130-150 otherwise certain Rhino functions fail with regularity. Especially fillets.

Quote - Generally speaking when something I've built renders up black like that the first thing I do is reverse the normals.  So far it's cured the problem every time.

Yeah Slinger, that would be the first guess, but I know the normals weren't reversed as I am anal about my models. I always analyze the direction of normals in Rhinocerous before they are ever exported for UVmapping and Poserizing. But nontheless I double checked the normals in the models I was having problems with and as I figured they were okay. Then I tried triangulating them, welding them, etc etc.. all the normal stuff hehe, but to no avail. Of course it urned out to be a FireFly issue in the end, but I had already wasted about 3 hours which bit into my project time which should have been finished last night. I just finshed it this morning thank goodness. No harm no foul though, but I am starting to hate P7 and FireFly :u)

Quote - Why would it need to be addressed?  You normally don't render something that small by itself, in which case there's no problem, and if you are rendering only a single item that small for some reason, scale it up before rendering.

Considering that some items in an older  product I am updating for P7 are figure embellishments, they are relatively small in scale. Therefore, I TEST them to scale when making them version compatible. I WAS UNAWARE OF THE BUG IN FIREFLY as I am sure others have run itno it as well, unaware.

Well, regardless, it's a bug in the software and should be addressed. Not that I don't see your point, however, had someone else not pointed me in the right direction as to the problem I could have spent countless wasted hours trying to figure out what the problem was (believing the issue may have been somewhere in my material settings or OBJ even though everything checked out).

Considering I am a content developer, wasted time is wasted $$$. No other rendering engines I use have this problem (regardless of the 3D software that I use.. Hexagon, Rhino w/Flamingo, Lightwave, DAZ Studio). IMHO I consider it a bug and should thus be addressed in any future releases or service releases.. this is what I would do as a developer, if I was aware of the issue.

Problem solved thanks to SVDL.

It appears that FireFly craps out when an object is small and this is the result. Adding a figure or larger prop to the scene solved the problem. Ummm.. a bug that should be addressed methinks.

~Will

Well I'll be damned if that wasn't the problem.

Thanks SVDL. At least now I can relax that it isn't a problem with my models hehe.

Thanks again!

~Will

Now I just need to model a beater (drumstick) ;o)

Here is the untextured drum. It will, when textured, have an American Indian motif on the skin. Again, rendered in Rhino.
I still need to model the drumstick ;o)

~Will

Untextured and rendered in Rhino. The existing color scheme is simply to show off the model a bit more and isn't final. The final model will be textured.

Thanks you guys! Any and all feedback is welcomed :o)

Yeah I hear ya. It would be nice if someone would design an app whereas you could load  the clothing figure and the the character of a figure it is based on, press a button and wahlah it analyzes and pushes the right vertices in place where they need to go or in an approximate (since a clothing item may have more vertices than the base figure it was designed on). If it could analyze and calculate shape and form and push the vertices relatively to where they need to be, that would be great. It would could also be a feature similar to Rhino's "Flow Along Curve" whereas you could define the shape by sectioning the base top to bottom and side to side and the siftware analyzes the shape against the mesh vertices and moves them appropriately. It's time like this I wish I was a top notch programmer.. I could most certainly rake in the dough with an app like that. :o)