Jump to content

Maya Upload Problems / Hair Modeling


Avant Scofield
 Share

You are about to reply to a thread that has been inactive for 4066 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

So I'm deleting history and reseting transformations before I upload, but for some reason all the separate objects are uploading as a super tiny jumbled mess, even though it looks perfect in the Preview window.

I can fix the jumbled mess with "Mesh > Combine", but now I can't texture each piece individually, so that's no good. Also, the group of objects were still squashed.

I tried changing the units on the exporter to fix the super tiny problem, but that didn't work for me. I haven't tried changing the units in a text editor yet, but I'd prefer a more solid solution.

I couldn't find a central thread about uploading mesh from Maya. Maybe someone can point me to one? The one in the SL Wiki is a broken link.

Picture included for scientific purposes: 
hairmonster.jpg

Halp please :o

 

 

Link to comment
Share on other sites


Vendetta Fhang wrote:

When you imported them seperately were they at least grouped together in maya?

If they were grouped in Maya, that might be part of the problem.  COLLADA exporters don't always understand heirarchy, and among those that do understand it, not all will deal with it in a way that SL can understand.

Whenever you're creating content for any external platform, it's best to avoid using anything that actively transforms or modifies the objects in the scene.  Heirarchy is one of those things.  To keep your scene organized, use layers instead of groups.  Layers are just a part of Maya's GUI, are entirely passive, and are completely ignored by exporters.

  • Like 1
Link to comment
Share on other sites


Avant Scofield wrote:

No, I get an error from the Collada exporter when I group anything. I just select all parts and Export Selection.

That sounds about right.  See my other post from a second ago. :)

 


Avant Scofield wrote:

I'm using Maya 2013 with the included DAE_FBX exporter.

Chances are your exporter is writing the wrong COLLADA version for SL.  Try exporting to FBX, and then use Autodesk's stand-alone FBX Converter (free to download from Autodesk's website, if you don't already have it) to convert the file to COLLADA 1.4.

If that works, then you can be relatively certain the problem was indeed the COLLADA version.  You can then try installing an older COLLADA plugin (2011 or older).  Assuming you get the plugin to work, it should solve the problem.  If not, the FBX Converter only takes a second.  It's less than ideal, of course, but hardly a showstopper.

  • Like 1
Link to comment
Share on other sites


Avant Scofield wrote:

Hi again Chosen
:)
You're still here being helpful as ever after so many years. LL should really be throwing money at you for this.

Heh, wouldn't that be nice?

 

 

 


Avant Scofield wrote:

I went ahead and tried your suggestion, but no dice. Downloaded this guy: 
and did the conversion, yet I still get the same tiny mess.

Hmm.  I guess it's not a COLLADA version problem, then.

What happens if you import the results back into Maya?

  • Like 1
Link to comment
Share on other sites

I'm assuming these are purple warnings, not red errors, correct?  When Maya says something in purple, it basically means, "I shouldn't have to do this, and I really don't want to do it, but I'll do it. Just don't blame me if it breaks."  When it says something in red, it's pretty much, "Oh, hell no!"

In this case, it sounds like the FBX plugin, for whatever reason, doesn't like the transform node that it itself wrote when it exported the file.  The warning, if I understand it correctly, is simply informing you that Maya is disregarding the node, and applying the translation, rotation, and scale info directly.

What options do you have enabled in the exporter?

When you select each of the objects before export, and after import, what nodes are present in the attribute editor?

What does your scene heirarchy look like?  Are objects perhaps parented under null nodes?

If disecting the scene further isn't your cup of tea, here's a band-aid approach that will probably work.  Export to OBJ, and then import the OBJ into a brand new scene.  Since OBJ can't include anything other than geometry and materials, problems related to scene structure and such should go away.  Sometimes that's the best way to clean up a borked scene.

 

By the way, does this problem happen with eveyrthing you export, or just with this one?

  • Like 1
Link to comment
Share on other sites

At this point it seems easier to just export to Blender. On my most recent Maya > Blender > SL upload there weren't any differences between the Maya and SL models. So hopefully this will continue to work and will be my upload method.

To answer your questions though: I had the standard options in the exporter, except that I tried a few different units, none of which solved the super tiny upload problem. When I select all the nodes, it only shows one in the attribute editor, which it always has. I don't have anything parented or grouped in my hierarchy.

I'm going to bed now cause it's late here, but tomorrow I'll try exporting to obj and testing with a new scene to see if I still get problems.

Link to comment
Share on other sites

So it looks like it was just that scene as I quickly made a new one and did my same process. I work with NURBS, apply some deforms and pull around the geometry, then convert to polys. The new scene still uploaded super tiny, but when I stretched it out, it wasn't a jumbled mess like the hair model. All parts were in place and not skewed on any axis.

My next fear is rigging/weightmapping the hair in Maya and still using Blender to export. Hopefully this won't be an issue, but it probably will! :P

Before I get there, I do have another question. Since I am working with NURBS, the vertices at the tighter bends in my hair start to really show when I convert to polys, unless I crank up the tesselation/smoothing for the whole model, which would be polluting! Is there a way to add more vertices just around the tighter bends?

Here's a picture:
hairprobs.jpg

Link to comment
Share on other sites

Aha, I've figured this one out on my own :)

If anyone else stumbles in here wondering how. I went into the settings for Convert NURBS to Polygons and changed the tesselation options to "per span #" instead of "per surf #". Then just need to make sure there's more isoparms in the areas you want more smoothing.

Link to comment
Share on other sites

I'm glad it was just a borked scene, and not something more serious.

As for the sizing issue, I'm guessing you probably haven't changed your working units in Maya from the default centimeters.  SL wants to see meters, so if you don't change it, your model will be 100 times too small, in-world. To stop that from happening, you can reset the working units to meters in your Maya preferences (Window -> Settings/Preferences -> Preferences -> Settings category), or you can edit it after the fact in the .dae file.   Or if it doesn't bother you, just resize in-world after upload.

 

Now that you've explained a little more about your process, and shown a wireframe, I have some additional tips for you.

First, I'd highly recommend you work directly with polygons, from start to finish.  Otherwise, you're only making things a lot harder than they need to be, and you're creating a ton of extra work for yourself. 

If you're used to the constraints of NURBS modeling, the increased freedom of poly modeling will take you a little getting used to, as will the mesh-specific tool set.  But once you do get used to it, you'll never want to go back.

To give you an idea of how easy poly modeling is, you could have solved your curvature problem simply by inserting a couple of edge loops, rather than doing the whole conversion from NURBS all over again.  Alternatively, you could have just moved some of the existing edge loops, in the same manner that you're probably used to moving isoparms when you work with NURBS.  (To select an edge loop in Maya, simply double-click on any edge in the loop.)

Also, so you know, it would behoove you to work with quads, rather than tris, for many reasons.  One is that Maya isn't always able to determine edge loops with tris.  Another is that when you need to subdivide, tris can get all kinds of messy.  It's best to keep your geometry as clean, and easily manipulable, as possible while you're working.  Once the model is done, go ahead and triangulate it, but not before.


I also have to point out that your model looks extremely poly-heavy, for what it is.  Because your source surface was NURBS, your polygon distribution is very even, in both directions.  As a result, you've a ton of polys where you don't need them.  For example, you don't need nearly as many sections around the circumference as you've got.  You could safely eliminate at least half to two thirds of them, and circumference would still read as round.

Additionally, the areas you labeled as "yuck" and "ew" and whatnot look perfectly acceptable for any real-time model.  That's about the level of curvature one would expect to see in those same areas on any professionally created game model.  Consider how small those areas will be on people's screens, and that they'll be surrounded by additional objects (the other locks of hair).  Nobody's ever going to notice that they're a little bit angular.

The edge loop your "mmm..." arrow is pointing directly at does not need to exist.  The span that that loop transects is more or less straight.  If you were to remove the loop, the model's appearance would not change in any noticeable way.  There are a couple of others that could maybe go as well, but that one is the most glaring.

All told, you could likely reduce the poly count by up to 75%, and the model would look just as good as it currently does.  That would also allow you plenty of overhead to increase the curvature in the "yuck/ew" area, if you really feel it's a must.

 

 

 

While we're on the subject of reducing poly counts, here's a quick public service announcement.  I realize there are some mesh modelers in SL who seem to think unnecessarily high poly counts are some kind of badge of honor.  They tend to say things that amount to, "Hey, check out this shiny new belt I made from 150,000 polygons.  It looks so smooth.  I did such an amazing job on it."   They get a few pats on the back from fanboys who have no idea of the realities of how these things actually work, and they convince themselves they're gods among men.  What those people don't realize is they're actually the laughing stock of the 3D modeling community at large.  Sorry, but it's true.

I encourage everyone not to fall into the same trap that those people have put themselves in.  Folks, when your poly count is so high that at typical viewing distance your individual triangles become smaller than the pixels that draw them on screen, you're doing it wrong, very very wrong.  There's no other way to say it.

A great mesh modeler is one who has mastered the art of doing more with less.  It's about using only as many polygons as you actually need in order to convey a shape convincingly, no more.  It's about striking the best possible balance between visual fidelity and performance, at all times.  It's about being mindful of the technical constraints of the platform you're modeling for, and doing what creates that best possible balance, on that particular platform.  It's NEVER about just throwing more and more polygons at the problem until you simply bury it, rather than solve it.

I really can't stress this point enough.  Keep those poly counts as low as possible, at all times.  Constantly look for ways to refine your models, and your own work procedures, in order to convey the same shapes with less polygons.  The more effectively you do that, the better a modeler you are, and the more respect you will earn from your peers all across the 3D modeling world.

 

(I know you're not one of the people I'm talking about, Avant, so please don't take offense that I happened to make the comment in your thread.  I've just seen enough exposition from that crowd lately that it was on my mind.)

  • Like 2
Link to comment
Share on other sites


Chosen Few wrote:

I'm glad it was just a borked scene, and not something more serious.

As for the sizing issue, I'm guessing you probably haven't changed your working units in Maya from the default centimeters.  SL wants to see meters, so if you don't change it, your model will be 100 times too small, in-world. To stop that from happening, you can reset the working units to meters in your Maya preferences (Window -> Settings/Preferences -> Preferences -> Settings category), or you can edit it after the fact in the .dae file.   Or if it doesn't bother you, just resize in-world after upload.

I've been playing with both that and the units in the exporter. The Standard Sizing Initiative downloads I use for rigging are set in centimeters so it's been a bit of a hassle but I've finally got that all sorted and I'm uploading at the right size now :)

 


Chosen Few wrote:

First, I'd highly recommend you work directly with polygons, from start to finish.  Otherwise, you're only making things a lot harder than they need to be, and you're creating a ton of extra work for yourself. 

I do appreciate your concern here, but I really think NURBS are the way to go for hair. I'm easily able to create smooth curves by only grabbing a few points and every adjustment is immediately smoothed, yet still editable. I have done poly modeling and would definitely use it for lots of other models, but for now I'm sticking to NURBS for hair.

 


Chosen Few wrote:

To give you an idea of how easy poly modeling is, you could have solved your curvature problem simply by inserting a couple of edge loops, rather than doing the whole conversion from NURBS all over again.  Alternatively, you could have just moved some of the existing edge loops, in the same manner that you're probably used to moving isoparms when you work with NURBS.  (To select an edge loop in Maya, simply double-click on any edge in the loop.)

Well, now that I know it will triangulate based on my isoparms, I shouldn't need to re-convert ever again :) Thank you for this info though - good to know for poly modeling.

 


Chosen Few wrote:

Also, so you know, it would behoove you to work with quads, rather than tris, for many reasons.  One is that Maya isn't always able to determine edge loops with tris.  Another is that when you need to subdivide, tris can get all kinds of messy.  It's best to keep your geometry as clean, and easily manipulable, as possible while you're working.  Once the model is done, go ahead and triangulate it, but not before.

This model was done, which is why I was converting it to polys.

 

 


Chosen Few wrote:

I also have to point out that your model looks extremely poly-heavy, for what it is.  Because your source surface was NURBS, your polygon distribution is very even, in both directions.  As a result, you've a ton of polys where you don't need them.  For example, you don't need nearly as many sections around the circumference as you've got.  You could safely eliminate at least half to two thirds of them, and circumference would still read as round.

Additionally, the areas you labeled as "yuck" and "ew" and whatnot look perfectly acceptable for any real-time model.  That's about the level of curvature one would expect to see in those same areas on any professionally created game model.  Consider how small those areas will be on people's screens, and that they'll be surrounded by additional objects (the other locks of hair).  Nobody's ever going to notice that they're a little bit angular.

The edge loop your "mmm..." arrow is pointing directly at does not need to exist.  The span that that loop transects is more or less straight.  If you were to remove the loop, the model's appearance would not change in any noticeable way.  There are a couple of others that could maybe go as well, but that one is the most glaring.

All told, you could likely reduce the poly count by up to 75%, and the model would look just as good as it currently does.  That would also allow you plenty of overhead to increase the curvature in the "yuck/ew" area, if you really feel it's a must.

The reason I'm working with this amount of sections is that I really do want a super smooth surface. I'm a huge gamer and I understand that the yuck/ew areas are standard polys in a lot of games, but not all (see: Far Cry 3). I have tried removing sections around the circumference to save polys, but it truly is noticeable in-world. This picture is also a little deceiving as it may read as a small strand of hair, when it actually scales across half the head profile. Even when at the default zoomed out level in-world, I could notice these points sticking out and I know it's something customers will complain about, especially when they compare with their other hairs.

Also, the span you're looking at where the "mmm" is pointing is deceiving again. It is actually farther away than you think. This hair piece is kind of fat and that span is just as separated as all the other vertical spans.

The other issue is texturing. The NURBS to poly converter is great for hair textures in that it keeps a generally even surface area. It would become quite a pain to adjust hair textures, not to mention cause more texture pollution as a trade off for poly pollution. The full hair model is about 15k vertices, and I know for a fact that a lot of the popular mesh hairs in SL right now are 20-30k.

Once I finish rigging, I'll post some pics at different tessellation levels or I could show you in-world.

 


Chosen Few wrote:

While we're on the subject of reducing poly counts, here's a quick public service announcement...

I agree with your PSA and I'm doing my best to follow suit as I learn. I'm having trouble believing people really brag about high polycounts, especially when there are entire communities dedicated to working with as few polys as possible. Funny and sad if it's true though.

 

Link to comment
Share on other sites

Unfortunately it is true about some people braging about high poly count and before that it was high prim count braging.

20k - 30k  poly for hair is much too high in my opinion. Here is an example of hair that comes out at about 8k done with poly only and not started from nurbs. As you can see it is smooth enough and the poly count could be even lower in some places.

hair01.png

Here is a rendered view.

hair02.png

  • Like 1
Link to comment
Share on other sites

That hair looks great!

I didn't doubt at all that it could be started from polys, but I personally work much faster with NURBS and I know the converter can produce very similar results, minus having to delete some faces after the conversion, which I'm guessing you must of had to do as well anyway?

Also correct me if I'm wrong, but I think this hair wasn't made for SL. Another reason I forgot to mention that my hair might be a little higher on the polys is because of SL's alpha rendering bugs out when we layer alpha textures. In order to get a nice messy hair look I'm having to layer pieces on top of eachother. I have worked around this in some areas.

I agree that 20-30k is too high and so is my 15k. My main issue at the moment is hidden faces. It's quite tedious to go in and delete all faces that are overlapping and Maya's "Clean up" tool only works for lamina faces, which are directly crashing. If I could find a script that deleted all overlapping faces I think my current hair would be a lot closer to 8k! I've used the avatar head to delete parts I had extended into the scalp. If anyone has any suggestions for these overlapping faces that would be much appreciated :)

Link to comment
Share on other sites

So, apparently alpha textures become ugly invisiprims when they're used on rigged mesh? Is that why I haven't seen any messy hairs done in mesh yet? Ugh :(

wtf.jpg

 

Well it looks like this lovely glitch is here to stay for the foreseable future. So my next task is cutting these prims and pulling them closer to the non transparent hair pieces to hide it as much as possible.

Link to comment
Share on other sites


Avant Scofield wrote:

So, apparently alpha textures become ugly invisiprims when they're used on rigged mesh?

This bug was first reported about a year ago, and it was one of those particularly odd ones that only seemed to affect some people. not everyone.  I was never able to reproduce it, myself.   It was supposedly fixed in a subsequent viewer update, not long after it was first reported.  Your case is the first I've heard of it since then (although that doesn't necessarily mean it's the first instance of it in that time, of course).

Out of curioisity, what viewer are you using?  Have you tried looking at it in different viewers?  Sometimes, detaching a rigged mesh, and then re-attaching it can solve certain graphical glitches; have you tried that?

Also, what graphics card are you using, and how current are its drivers?  What OS?

Link to comment
Share on other sites


Avant Scofield wrote:

I personally work much faster with NURBS

If that's the case, then I have to assume it's just because you happen to have had more practice with NURBS modeling than poly modeling? 

So you know, if you really want to, you can perform virtually all the same maneuvers with poly surfaces as with NURBS surfaces, by using various deformers and/or proxies.  But you can also do countless other things with polys that you could never do in a million years with NURBS.  Once you're well experienced with poly modeling, you'll kick yourself for ever having thought NURBS modeling was faster.  For most things, it's quite the opposite (with sculpties remaining a notable exception).

NURBS were first developed for the industrial design world, and were semi-adopted in the film world for a while, both fields in whiich the advantage of infinite resolution trumps inherent drawbacks of a NURBS-centric work flow..  For game artists, NURBS don't really do a whole lot.

Where SL is concerned, Maya users may have an unusual attachment to NURBS, since they were the original surface source type for sculpties.  There were some good reasons for that at the time, but we're well past all that now.  For mesh modeling, the best source is, well, mesh modeling. :)

 

 


Avant Scofield wrote:

I know the converter can produce very similar results, minus having to delete some faces after the conversion, which I'm guessing you must of had to do as well anyway?

I'll leave it to Raster to explain his/her techniques, regarding his/her own creations.  I will say, though, that adding and deleting faces during the poly modeling process is as natural as breathing.  It's doesn't have to be like with NURBS, where most of the time you're manipulating an existing surface.  With poly modeling, you can (and do) actively create and destroy as you go.

 


Avant Scofield wrote:

Also correct me if I'm wrong, but I think this hair wasn't made for SL.

Again, I'll leave it to Raster to explain what his/her creation was or wasn't made for, but I have to say that that hair model looks perfectly viable for SL, to me.  It lacks that overly tubular "sculpty-hair" look that so many SL hairpieces have, but I think that's precisely the point.  Arbitrary mesh can look so much better than sculpties, or sculpty-style models.

Consider that in RL, locks of hair do not tend to be so cylindrical.  Often, they're quite flat.  So why limit them to cylinder-based construction in a model?

Raster's model looks to be far more plane-based than cylinder-based, which is the way it's typically done.  It not only looks better that way, it uses far less resources.  Total win-win.

That's not to say yours looks bad, by any means, so please don't take any of this the wrong way.  It looks as good as any sculpty hair I've ever seen.  It's just not (yet) taking advantage of what arbitrary mesh modeling can do.

 


Avant Scofield wrote:

Another reason I forgot to mention that my hair might be a little higher on the polys is because of SL's alpha rendering bugs out when we layer alpha textures. In order to get a nice messy hair look I'm having to layer pieces on top of eachother. I have worked around this in some areas.

All the same alpha sorting problems will happen in any real-time environment.  SL actually handles it better than a lot of game engines do.

While it's true that were it not for the alpha sorting glitch, one could conceivably use less geometry for a hair piece, the difference really isn't as great as you might think.  When I create messy hair pieces for characters, they're typically 2000-8000 polys, depending on length, regardless of the presence or absence of alpha.

 


Avant Scofield wrote:

My main issue at the moment is hidden faces. It's quite tedious to go in and delete all faces that are overlapping and Maya's "Clean up" tool only works for lamina faces, which are directly crashing. If I could find a script that deleted all overlapping faces I think my current hair would be a lot closer to 8k! I've used the avatar head to delete parts I had extended into the scalp. If anyone has any suggestions for these overlapping faces that would be much appreciated
:)

I gotta defer to Mr. Miagi on this one (and I mean the real Mr. Miagai, not the remake wannabe!), "Best block is no be there."  In other words, the very best way to deal with hidden faces is just not to create them in the first place.  By working with polys from start to finish, instead of beginning with NURBS surfaces, you can create arbitrary shapes, rather than limiting yourself to just rectangular topology.  Those arbitrary shapes can preclude hidden faces having to exist at all.

Learning to work without creating a lot of hidden faces is pretty much a rite of passage for all new modelers.  People almost invariably create a ton of them at first.  Eventually, something clicks, and you start seeing pathways around the problem as you work.

That said, in instances where you do have hidden faces, if it's tedious to go in and remove them by hand, so what?  Artwork is a dirty job.  To do it well, you have to be willing to stick your hands in it, and squish them around. 

The more you look to broad-sweeping tools like converters and cleaners and whatnot to do the work, the more you only hold yourself back.  Automation will only get you so far.

  • Like 1
Link to comment
Share on other sites

The alpha glitch happens in the newest default viewer and newest Firestorm. All my friends I contacted were aware of it. One person said that it only affected water and "png textures" but oh well. I've cut these down and pulled them closer to the hair so people experiencing this glitch won't notice it nearly as much as in my last picture.

And I do appreciate all your points on poly modeling Chosen, though like I said, it's not completely alien to me, I just prefer it for hair. I do think working with polygons is superior for pretty much everything besides hair and maybe snakes :) Lattices and deforms just don't give me the same results and ease as pulling around NURBS curves. With isoparms I can evenly distribute the density of polys as I see fit without having to pull them manually. Then, after converting, I can work with polys to remove faces and fine tune it.

The advantage I can see polys having is creating a hair like the one Raster posted, out of planes. I'm aware this is usually how hairs are made in games, but I don't think they work so well for SL because of the alpha issues. Whether SL is better than other engines at sorting or not, it's proved painful in my experience and I'm sure that Raster's hair would be switching between visible layers all over itself in SL.

 

 

Link to comment
Share on other sites

Sounds like you're pretty well married to your NURBS-to-poly procedures, so I'll let that subject drop. :)

Here's a tip that may help you with your alpha issues. This may well have occurred to you already, since I know you're already practiced in how to work around the alpha sorting glitch.  But just in case it hasn't...

Use two materials, rather than just one, and create two versions of your hair texure, one with alpha, and one without.  Apply the 24-bit version to most of the length of the hair, where you don't need transparency, and put the 32-but version only on the ends, where you do.

 

As for the invisiprim-like bug, I'm still unable to recreate it, so I'm afraid I can't offer any advice there.  Seems it's as true now as it was a year ago that it only affects some people, and not others.  I wasn't able to make it happen then, either.

 

 

Oh, and just so nobody reading gets confused, the person who said the bug only affects PNG textures could not possibly have been correct.  I take it from Avant's "oh well" that he's well aware of this. 

To be clear, SL does not and can not have any way of knowing what a "PNG texture" is or a "TGA texture" or anything else along those lines.  When you upload an image to SL, it gets copied to JPEG2000 format, as a first step, BEFORE the actual upload process begins.  What gets uploaded is the JPEG2000 copy, NOT the source file.  The source image never leaves your local hard drive.

The JPEG2000 save process is NOT capable of differentiating between input formats in any way.  It physically CANNOT make an image sourced from a PNG come out different than one sourced from a TGA, not in any way at all.  So, the end result is exactly the same, no matter what the source format happened to be.  It simply cannot be otherwise. 

Further, even if there were a difference in the files (which I repeat, there is NOT), it still wouldn't make any difference to how the image behaves on screen.  The renderer doesn't know anything about files.  By the time the data gets to that point in the graphics pipleline, it's basically just pixels, nothing more than a collection of color and transparency information to be processed and drawn, no longer a file to be saved.  There's absolutely no way that the file format can affect the drawing process at all.

People who insist there is any kind of difference are victims of their own ignorance, nothing more.  As I so often try to remind everyone, this stuff doesn't run on magic.  The same laws of physics and computer science apply to SL as to any other program.

  • Like 1
Link to comment
Share on other sites


Chosen Few wrote:

Use two materials, rather than just one, and create two versions of your hair texure, one with alpha, and one without.  Apply the 24-bit version to most of the length of the hair, where you don't need transparency, and put the 32-but version only on the ends, where you do.

I'm doing this already! :) The lower section with the alpha gets a little SL shadow on it showing the seam, but it's worth the payoff of having more alphas. Also, it can be a bit tricky to rig. I made the cut at the neck and it took quite a long time to get it to look okay when the head turns.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4066 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...