Page 3 of 3
Posted: Fri Oct 27, 2006 6:48 pm
by minilogoguy18
well even if the model works in game with a high polycount its still not smart to do cause just think whatll happen when you have a bunch of them all over the screen, the games gonna lag and one thing i notices too is that effects stop appearing cause the game has run outta physical memory. also, dont use sub-d surface modeling, its always gonna come out too high cause the sub-d primitives have 10 times more actual polies, they just have less surfaces but thats cause theyre different types of geometry, but i wont get into that, just use polygon meshes.
Posted: Sun Oct 29, 2006 8:59 am
by Qdin
Maveritchell, you can't use the 'I didn't knew the limits' as an excuse when it's clearly listed and exlpained various places what the limits are and why - even the reason is logic, like mini' said

Posted: Mon Oct 30, 2006 4:45 pm
by Maveritchell
Qdin wrote:Maveritchell, you can't use the 'I didn't knew the limits' as an excuse when it's clearly listed and exlpained various places what the limits are and why - even the reason is logic, like mini' said

Pardon the misunderstanding - I'm not claiming ignorance of the suggested limits, which are pretty clear in the docs (although for such a simple unitmodel, mine should probably be
below the suggested range).
I, perhaps, made a mistake in posting the full mungelog - like I said, I knew what the poly warnings meant. I knew, before I even munged it, that my model had too many polies. I knew that it probably needed to be fixed.
All I really wanted to know - and I suppose I should have made that clearer - was what the errors pertaining to the collision geometry meant, and here's why: the model had already successfully been put ingame. The only thing that was different between the first model that was put ingame and the one I tried to munge was that on the second one, I made sure there was a hp_weapon null.
So, between two models with essentially no change in geometry, I got the warnings: "ERROR[PC_modelmunge msh\t3mod.msh]:NO COLLISION TREE WRITING ALL ZEROES FOR BOUNDING BOX" and "ERROR[PC_modelmunge msh\t3mod.msh]:Unable to write collision tree nodes, no tree exists." Why the change for the second version of the model?
EDIT: In other news, trying to envelop the mining droid model to bones is a pain in the keester. As much as I hate to just straight-up ask someone to do the work for me, I will. Because it's just no fun for me to try and work this out... and, after all, isn't all this supposed to be fun? Anyway, if you're pretty certain you can attach the bones to a four-legged model, and get it to walk (even if each leg pair has to move together), I would be in your debt.
Posted: Tue Oct 31, 2006 4:34 pm
by Qdin
make a new skeleton and animate it after that, I think it'd be the best
Posted: Wed Nov 01, 2006 7:11 pm
by Vyse
Qdin wrote:make a new skeleton and animate it after that, I think it'd be the best
Something as simply as a droid, I would make the new skeleton out of nulls. That would be way easier in the long run.
Posted: Wed Nov 01, 2006 9:34 pm
by minilogoguy18
no way vyse, you just havnt discovered the magic of constraints and full inverse kinematics, over the past short while i learned how to make full custom rigs and once you make one for a model it makes it so incredibly easy to animate cause you can animate an entire limb just by moving a simple controller.
Posted: Thu Nov 02, 2006 12:18 pm
by Vyse
I just noticed he has a larger droid model. I was refering to the Smaller T3 unit.
Would it still be better to use a rig on such a small droid? I would agree that bones are nicer to animate. I couldn't imagine animating human skeleton out of nulls.

Posted: Thu Nov 02, 2006 1:01 pm
by Maveritchell
Vyse wrote:I just noticed he has a larger droid model. I was refering to the Smaller T3 unit.
Would it still be better to use a rig on such a small droid? I would agree that bones are nicer to animate. I couldn't imagine animating human skeleton out of nulls.

Yep, the larger droid was what I was referring to when I inquired about your spider animating in your HF map. The mining droid (for that is what the larger, spider-like droid is) is unit-sized, though, it's not terribly larger.
Anyway, this has fully and completely gone beyond my realm of experience. I'd love to actually get this map done, but I feel like I'm getting caught up in the minutae of creating unit models, when I've still got an indoors level to model, more weapons to create, and of course all the setting up of the level. And all this, with essentially no help.
Not to be a baby, but that - for me - is a substantial amount. I've seen all of you take on tasks equal to or greater than this, and I know it can be done. However, I feel that among all my responsibilities, this falls somewhere at the end of the list. I'd love to get this map done, or at least get substantial work done on this, before it turns into a job for me, and no longer a pastime.
So I'll straight-up ask for help. If you know you can rig and animate this model (the mining droid), I would ask that favor of you. I know we've all got our projects - and these are just hobbies, after all - but if you've got the time and you're willing, please, help. (...me Obi-Wan Kenobi, you're my only...)
Posted: Sun Nov 05, 2006 11:38 am
by Qdin
LOL Mini' xD you didn't knew that before?
it really makes it easy
The only thing I'm wondering about right now, is whether we can add some IK's to the skeleton without screwing up the animations...

Do you know if we can?
Maybe you should make a video tutorial about that instead?
