Lately I've been delving into some deeper 3d apps and concepts.  I've been trying to make clothes and hair using tools instead of pushing around vertices all day.

When I get comfortable with a task, I tend to get very very good at streamlining things and making workflow efficient.  I see better ways to do things.  That has been happening in my experiments, yet no way to implement my ideas.  Further, I see what people want to do in this forum and I watch as the responses pile up that are more and more ridiculous because every advanced idea requires not tools, but endless workarounds. 

So, here's some thoughts on tools, options and things that should exist.  Primarily in Poser, but some of these apply to high-end applications where I would think it would be a no-brainer.

1.  Fresh off the top of my head, I saw the hand-deform boob thread here and it occured to me right away.  "Why only sphere zones for poser magnets???"  We should be able to have object/shape based magnet zones.  If I wanted to squish a breast I could load up a magnet on the hand and change the zone to a hand exported in the pose that has the hand shape for the deformation. 

2.  Which leads me to my next thought.  Shrink Wrap.  Sometimes you just don't want gravity, you want something to shrink.  In Poser, you can't turn gravity off.  Why???  Further, where Shrink Wrap exists in other apps, it fails because if the object is open-ended, then you end up with the wrap on both sides of the target which is a nightmare in itself.  If you cap the holes, it deforms the uppermost edges and in a hi-res situation there's just not enough time in the day to delete the tops when you're done.

3.  The Cloth Room.  Does it need to be a room anymore?  I should be able to load and pose a V4, load a dynamic cloth, and Poser should just calc out everything based on the settings in the cloth PP2.  If I want to tweak it, THEN take me into the Cloth room.  And by the way, don't make me create animation frames i don't want.  Let Poser create it's own math in a subroutine and keep it out of my workflow.  When I eventually do make an animation, let Poser understand that the dynamic cloth needs to go with it.  Will it take longer?  For now.  But not that much on a good modern computer.  Thanks to clo3d, we now know that we can do this kind of stuff in near-real time.

4.  Clothing and Body Morphs.  For Dynamic clothes, number 3 takes care of this.  For Conforming, Clothes shouldn't have to contain morphs anymore.  Thanks to "conforming Clothes" by dimension3d, we know that body morphs can be calculated on the fly in zero time and added in to the cr2.  I assume this could also be done in memory.  It could do it every time you change a dial, so that only what you use gets saved.

5.  Automatic Symmetry option for Magnets.  I check the button, the result is duplicated on the opposite X axis point.

6.  Quadrify modifiers that really work.  I think we need this.  I'm not really sure.  Used to be Poser needed Quads.  I'm not even sure if that's still true.  But I've been trying to play it safe and go with quads whenever possible.  Problem is?  All the good toys don't make Quads.  Clo3d doesn't, 3dsmax Garment Maker doesn't.  I don't know what else, but if these trends remain consistant, I'm guessing nothing cool uses Quads. 

Well most of these apps have a Quadrify button, modifier or Wizard.  The problem is, none of them actually seem to quadrify anything, or, if they try, they leave a bunch of non-quads in their wake. 

The "community" seems to be going into a different direction called "Retopo" which basically means create a whole new mesh, based on the original, with neatly lined rows and columns of quads.  The problem?  No workable automation of this process.  You've gotta "get in there" and toil for almost as many hours as it would've taken you to just do the whole thing manually in the first place.  One auto-retopo tool exists for max, but, again, it's only meant for solid objects.  So, something like a piece of clothing is RIGHT OUT.

How about you just go ahead and compute a Quadrify properly in the first place?  By the way, Yes, i don't want to lose my UV mapping or my material IDs.  You're a computer, COMPUTE DAMN YOU. 

7.  Curl Modifier.  I've got twists and warps aplenty, but no curl.  Why???

Okay, I think I had more but I'm too pissed off at the above to recall what else.  I'll add later if I can think of anything.

1. for the hand-deformed boob, they could also paste an hand-shaped displ.map onto the boob map area.  bill has showed how to generate said map using poser depth cue function.

2. they've still got the "curve" parameter in poser.  in the old days it was used largely for snakes and dragon tails, but now apparently it can be used for other joints.

For number two, I'd kind of like to be able to set the direction or intensity of gravity.  It might be useful in some cases to set gravity to the center of a cloth object, to have it deflate like a basketball, say, or wrap an object with cloth effects on the wrapping object.  I've done this with a script, so it can be done, but Python for this sort of thing is slow under the best conditions.  If the intensity could be reduced to zero, that would meet your needs, too.

For the boob thing, erm, some kind of soft body dynamics would be neato-keen.  But so would fluid dynamics, physics simulation, and more accessible hair design tools which allow numeric or dial entry as well as interface dragging.  :unsure:

Have you seen the auto retopo for 3D-Coat?  It's supposed to be the best out there right now, requiring only that you define key edge loops.  I haven't tested it yet, but phantom3D has shown some nice results with it.

I'm not sure what you mean with number seven.  A curl modifier like the wave deformer?  Or a hair shaping tool? 

PhilC has a shrink-wrap utility in his Tool Box.

http://www.philc.net/PTB_page2.php

lmk

6- Triangles are most used because render much faster than quads. On the other side quads have more efficient memory use and produce a better mesh topology.

The wise solution: Use quads and subdivide each quad in two triangles at rendering time.

Quote - The wise solution: Use quads and subdivide each quad in two triangles at rendering time.

Unless you're triangulate every single quad by hand, I don't see how that's particularly useful compared to what pretty much all 3D apps including Poser do with quads (triangulate them automatically internally).

Quote - > Quote - The wise solution: Use quads and subdivide each quad in two triangles at rendering time.

Unless you're triangulate every single quad by hand, I don't see how that's particularly useful compared to what pretty much all 3D apps including Poser do with quads (triangulate them automatically internally).

The subdivision into triangles is done by the computer and not by you.

To render a quad you need divisions for the interpolation, rendering triangles only requires addition.

Quote - The subdivision into triangles is done by the computer and not by you. To render a quad you need divisions for the interpolation, rendering triangles only requires addition.

I don't really get what you're saying here.  Internally, all quads are cut into triangles, both in preview and in render, automatically.  This is normal for any 3D app I've worked with.  You can triangulate the model for use with stuff like game engines that aren't designed to handle quads, but nobody does this for Poser or other general-purpose 3D apps.  While I haven't benchmarked it, I think it very unlikely that manually triangulating a model of any polygon count that is all quads has any impact at all on render time.  I don't see any practical use of trying to do this, other than preparing a model for specific game engines that don't work with quads.  Am I misunderstanding what you're saying?

Quote - I don't really get what you're saying here.  Internally, all quads are cut into triangles, both in preview and in render, automatically.

You can render a quad without dividing it into two triangles. Today with SSE division maybe you can render faster a quad than two triangles. I have not tested it yet.

Quote - I think it very unlikely that manually triangulating a model of any polygon count that is all quads has any impact at all on render time.

It is slower, a model made with triangles consume more memory(1.5x)  and so, more memory access.

I think you're not understanding. Every render engine turns quads into triangles because all a quad is is two triangular polygons.This is just how render engines have worked going back as far as I can recall. So manually doing it seems a waste of time, if the computer is doing it for you.

Subdivision, the act of increasing mesh density, is something else entirely. I think you are confusing the two.

A render engine will turn a mesh into triangles at render time so that it is easier to process - even if you choose to subdivide at render time, it will first do the subdivision and then the conversion to triangles.

A model made with triangles is not the same as made with quads.

If the quad is a convex quad with its four vertices belonging to the same plane then there will not make difference to two triangles, but this is not always true and a mesh can have concave and not planar quads. A degenerate quad can render with shading artifacts. Even if the mesh is well done with good quads, if you deform the mesh the deformation process can create degenerated quads. A mesh done with only triangles always render without shading artifacts.

The other problem in dividing a quad into two triangles is that there are two ways to divide a quad into two triangles and an automatic subdivision not always pick the right way for each quad.

guys... he's not going to get it. trust me. he's off on one of his "I'm not listening to you" jags. nothing you can say will make a difference.

The computer will still interpret it as tirangles though. It may not do it well, i know that is true and in which case you can then go in and define the triangles that make that particular quad if you need to do so. Ultimately, the computer still sees it as a triangle - convex, concave, etc, doesn't play into how the computer attempts to treat it. At the end of it all, to the computer, it's all triangles. They may not always convert well but the conversion is something it always tries to do. This video touches on it somewhat:

http://vimeo.com/2159588

Quote - guys... he's not going to get it. trust me. he's off on one of his "I'm not listening to you" jags. nothing you can say will make a difference.

Well that would be unfortunate but everyone has their views, right or wrong, you have your right to them. Anyways, I'm going to go model something now that I've started my vacation. You folks have fun.

well I was just trying to save you the frustration that arguing with him brings..... (well documented!)

You forgot about texture mapping; it makes a difference if a quad is divided into two triangles or not, even if the quad is planar (see image). Since the quad on the left looks more visually appealing for most users than the one on the right, it is usually better to give the renderer quads, not tris; so the old rule of quads being better than tris still holds. In my opinion, you should give the renderer what corresponds to your model the most; the renderer will try to make the best of it and, as pjz wrote, convert to triangles anyway if necessary.

In any case, Poser's firefly renderer does not only not convert everything into triangles, but moreover converts everything into quads during the renderering process (read about it in the "clothing for dummies" thread), unless you fiddle with the rendersettings. I do not know what most renderers do with the geometry, but e.g. Pixar's Renderman and 3delight (daz-studio) are doing the same, while e.g. blender and a classic OpenGL implementation indeed convert everything to triangles.

I don't mean to start a fight about it, I'm just wondering if we're not all on the same page, that's all.

Many renderers chop everything into triangles, but definitely not all of them. Millighost posted one good example why two triangles are not necessarily a good representation of a quad.

I figured there are some apps out there that don't, which was why I hedged with "pretty much", but I can't name one that doesn't.

Quote - I think you're not understanding. Every render engine turns quads into triangles because all a quad is is two triangular polygons.This is just how render engines have worked going back as far as I can recall..

Is what you think, many rendering engines can render a quad directly and some that are more rare can render a ngon or patch. The first rendering engine that I did rendered quads, later I discovered that rendering two triangles was faster than rendering a quad. In any CG book you can find how to render a quad without dividing into triangles.

Quote - Subdivision, the act of increasing mesh density, is something else entirely. I think you are confusing the two.

Dividing a quad into two triangles is not a subdivision? then what is subdivision? Or have I to divide a quad into 4/8/... triangles to be a subdivision?

I believe that today with the current CPUs render a quad will be much faster than render two triangles.

Cutting a quad into two triangles is usually called tesselation.  "Subdivision" usually refers to one of the common schemes of cutting all polygons in a model via mathematical means (Catmull-Clark, Doo-Sabin or other algorithms).  I think you are aware of this stuff, just we're using different terminology.

This image is a projection, the four vertices are not in the same plane and so, the two edges do not intersect.

This kind of quads are common to happen bending body parts of a Poser's figure.

Unsubscribing... :blink:

ricardo, when one divides a quadrilateral into triangles, it's called "triangulation".  in the past, some softwares would do this to poser figures on import (default settings), hence if one weren't careful, morphs created in those apps would not match the body part when attempting to import them back into poser as morph targets.

Quote - How do you divide this quad into two triangles?

That's what I'm saying, it's done automatically internally by the app (e.g. Poser).  I don't think this is a matter that people really care about, certainly as a modeler I don't worry about it.

Quote - How do you divide this quad into two triangles?

The same way as a planer (true) quadrilateral, by connecting one pair of non-adjacent corners. As an exercise, calculate the sum of the internal angles of your non-planer shape and post it.

sum=360, and I'm guessing poser would have trouble rendering non-planar quads.

Why would you think that?  In a great variety of models, the individual polys will not be planar.  Poser has no trouble with this.

LMAO

ok 2 dead... tho the one in the santa hat's still giggling...

Poser renders quads as thousands of quads. It renders triangles as thousands of quads. There are no triangles in Poser. Lower the shading rate and it will render a single triangle as millions of quads. Each tiny little quad (aka micropolygon) is flat shaded and so it doesn't matter if it is non-planar. This is true of all REYES implementations.

Note: My XML to terminate myself was properly terminated. The rest of you are dangling.

Quote - 1.  Fresh off the top of my head, I saw the hand-deform boob thread here and it occured to me right away.  "Why only sphere zones for poser magnets???"

Because the math is simple for a sphere. A point is not affected if it is outside the sphere. If inside, the distance to the center of the deformer defines the index into the deformation function quite trivially. It's not so simple for a hand.

Quote -  We should be able to have object/shape based magnet zones.  If I wanted to squish a breast I could load up a magnet on the hand and change the zone to a hand exported in the pose that has the hand shape for the deformation. 

That would be cool, but it's even harder than cloth self collision and I'm pretty well convinced that isn't working right either.

I'm not sure how Ockham's Eureka script works, but it deforms things at the Y-axis (like someone sitting on a pillow) by selecting which is the hard and which is the soft part. If something like this could be taken further (so it worked in all dimensions and not just downwards), a thing like the hand-on-a-breast would be a lot easier to make.

In response to the (now deceased) OP
I would wager that All of those features he requested are available in
Blender or can be programmed in with python.

Cheers