universal advertising (Part II)

[zaroba]

also you need to make sure that EACH keyframe model has the exact same number of faces, or the model convertor wont let you use it.

[fhko]

*bangs head on keyboard*
Now I have to start to learn how to use another animation style...I already had a real tough time getting those lousy log halves to stay together until just the right time when they rolled apart nicely...without gmax trying to make them go in odd directions that only a computer would think I wanted...(things aren't supposed to move perpendicular to the way a conveyor belt is heading)...

these keyframes you speak of...do they have to occur at evenly spaced intervals of time...or can the time between each be varied?

don't even start animating until you're absolutely sure you've finalised the uvmapping.

Oh Jaye...

[zaroba]

you can set the time that each one takes in milliseconds.
and easily change them till your happy

[Jayecifer]

Oh Jaye...

Yes? You called?

[fhko]

Might you be interested in texturing this thing for me?

[Fooli]

*bangs head on keyboard*
Now I have to start to learn how to use another animation style...

Well, not really. Generally you have to go thru the motions of the full animation in your modelling prog so you know it'll work. The skill is in understanding how the final keyframes will fit together in the game, so you only animate the stuff that's gonna matter in the end. Gmax uses keyframe animation just like the game does - it's the same thing, it's just that you can't export the whole animation directly.

I already had a real tough time getting those lousy log halves to stay together until just the right time when they rolled apart nicely...without gmax trying to make them go in odd directions that only a computer would think I wanted...(things aren't supposed to move perpendicular to the way a conveyor belt is heading)...

There's something quite important here. What you're experiencing, almost certainly, is a "reset transforms" problem. Hard to explain, but... let's say you're building the log part of your model. You mess about with the scaling, you add some modifiers to the stack, you rotate it a few times, change your mind, rotate it back again. Finally, you end up with the log you want in the right position. Ok. But sometimes all that transformation work (moving, scaling, rotating, adding modifiers) will confuse the hell outta Gmax.

So, once you've got the thing looking like you want it, save a copy; then collapse the stack (right click it and choose "collapse to mesh" or whatever the option is). It's like merging layers in a paint prog, or producing the "final mix" in a sound prog.

And then, it makes sense to do two more things: to "reset transforms" on the model (there's a specific tool for this, though I dunno where it is in Gmax off the top of my head). When you do that you'll normally see the bounding box change. It's basically telling Gmax "no, this is the right "final" form for this model". Once you've reset transforms, it helps to collapse the mesh again. And then you should be able to start animating without any weird perpendicular movement or whatever (which is just Gmax getting confused by all your previous fecking about with that bit of the model).

Of course, collapsing the stack will also kill any animated effects you might have included in there. It's perfectly valid to use stack modifiers to do animations but it makes sense to do those last: once you've got the basic mesh in place, collapse the stack, reset transforms, then proceed with your stack-based animation method (prolly you're not using that but just in case... :)

these keyframes you speak of...do they have to occur at evenly spaced intervals of time...or can the time between each be varied?

Good question. Let's see, how to explain this.... you need to understand how the game's vertex animation system works. Vertex animation is just a simple form of linear animation. For example, you have keyframe A, and keyframe B. They have to have the same number of vertices in the same order (like zar's comment about number of faces, above). When you animate from A to B, the game simply looks at vertex number 1, and moves it from its A position to its B position. Then vertex 2, 3, 4 and 5 to 54,000 or whatever.

So how does this answer your question... well, it's like the simple/complex animation examples I gave in my original reply. If you want to move a log in a straight line from A to B, you only need two keyframes. The game will simply move each log vertex from its starting point to its finishing point. You could do it with 8 keyframes or 1,000 keyframes but the end result would look the same. And, the time spacing in Gmax doesn't really matter because you can control the speed of the transition from A to B in the model converter.

With two frames, if you wanted the log to take 2 seconds to move from A to B, you just set the model converter to play each frame for 1000ms. With 8 frames, you'd make each frame play for 250ms. And with 1,000 frames, they'd all be 2ms long and you'd be an eejit. But it'd look the same.

However, if at the same time you had the crane arm rotating, picking things up, dropping them: then it all gets a lot more complex. You'd need to think about the whole animation, from start to finish, and it's much more likely that the time spacing between Gmax keyframes would become important, especially if the crane's movement and the log's movement took different amounts of time.

So let's say it takes 16 frames in Gmax for the crane to move, and it takes 10 for the log to move. At frame 8 in Gmax, the crane's half way round but the log's almost finished. Because you'd probably want the crane and log movement to be smooth - no sudden accelerations etc - you'd need to animate the whole thing in Gmax and export all 16 frames. For the last 6 the log wouldn't do anything but the crane would; end result, lots more frames than just A to B but you get the effect you want. And in the model converter, you'd end up with 16 keyframes all playing for the same length of time.

This is really tricky to explain in words :)

Oh Jaye...

Heh. Even worse, it is. You're gonna need to do the uvmapping before anyone can texture it ;)

This is prolly a discussion better suited to the developer's board, if you want it to continue. I'm glad you're using Gmax though: I'm planning to make some tutorials on it, cos while it has its own idiosyncracies (it's basically 3ds Max 4, which is years old now) it is extremely powerful and very much oriented towards game modelling.

f

[Jayecifer]

Heh. Even worse, it is. You're gonna need to do the uvmapping before anyone can texture it

Thank the heavens! If I do it and I can't UVmap it with box mapping I'm liable to just use facet mapping in Bodypaint 3D and the texture will look fine on the model, but no one in their right mind would be able to modify it as it would look like lots of triangles spread out... so when you get the UVmap done Fhko, just e-mail the model to Jayecifer@aim.com.

[fhko]

I'm probably about half way done with pulling apart the various parts of the UV Map into a slightly discernible order...what file type will you be wanting the model in when it's done...will .3ds work?

EDIT: I've finished the mapping...


For my first mapping it went pretty well...especially for something so darn complex...and there was only one piece I wasn't exactly sure where it was supposed to go ...

Does it look simple enough or will changes/explanation be required?

[Jayecifer]

Yeah, I can handle that. If I need to I can just modify the UVmap. You did a good job. Bravo.

[Fooli]

Cool, you've passed the first test - being able to cope with the boredom of uv mapping a complex model. Congratulations.

However, eeeek. Ok, I guess this is ur first time... so this is criticism of the hopefully constructive kind:

1) the uvmap, like the texture, should be "power of two" in size. That is, something like 256x256, 256x512, 512x512, 1024x512, 1024x1024 etc etc.

2) there's an awful lot of wasted space on that template. It'd work, sure, but the "correct" way of doing it is to hand-optimise the spacing so you use as much as possible. Ideally you need only 1px between each chunk of uvw data (2px to be on the safe side)

3) there's at least one overlap there... each bit of the model should have its own bit of the texture (eg, the boxes with the horizontal line, mid-right...).

4) seams. Worrying about seams is always important. Sometimes it's crucial, depends on the model. Here, we have a bunch of wall bits and roof bits and so on, all of which seem to be separate. It'll work ok, especially if you have a good texture person, and if the final texture is gonna be simple. But, especially with walls, you typically want to connect as much of the adjoining uvw bits as possible. Imagine you try to paint bricks onto the wall bits. Well, you want to do that in a seamless way, so that you can line up the brick pattern on adjacent walls. Or roof tiles, and so on.

Mapping is always about compromise. And there's nothing especially wrong with what you''ve done here, apart from the overlaps and the aspect ratio of the image. But as I've hinted above, it's about experience, and experience tells me this will be tricky to texture for all the reasons I've given above. I bet Jaye proves me wrong tho :)

First time effort, bravo indeed. But it's a feckin complicated thing to do right, and no mistake ;)

f

[fhko]

The overlap I think your talking about is the pole between what looks like two boxes...it's supposed to be like that because in actuality the pole runs into the inside of each of those...would be pointless to separate...

even though the screenshot might not show it...the UVMap corresponds to a 512x512 texture

and the seams...well...I never liked sewing...

[Fooli]

Ooooh, well lookeee here. Already breakin' the rules cos it makes sense to :) Well that's fair enough then if the overlaps are hidden :)

512x512, cool. I think of seam work more like rivetting or something manly. It helps to ease the pain :)
f

[Jayecifer]

I bet Jaye proves me wrong tho

While I think I'll have minimal trouble texturing this I would just like to point out that I still prefer your style of mapping Fooli. It makes my job about 30% easier. Perhaps a "Form, Function, and Design In UVmapping" tutorial is in order.

[zaroba]

mapping is somewhat a preference.

its easier to retexture models mapped like fhko's where each face has a seperate spot on the texture to use. can add words, designs, etc, etc.

[Jayecifer]

I've got a start going. There are a lot of unnoticeable errors in the UVmap.

You know, we should have more threads like this. Where we all sit around and help a nice model through to it's completion.

[Fooli]

mapping is somewhat a preference.

its easier to retexture models mapped like fhko's where each face has a seperate spot on the texture to use. can add words, designs, etc, etc.

There are different ways of mapping models, sure, but I'm not talking about combining faces (although that's perfectly valid, especially for repetitive models). I'm talking about welding the uv coordinates of faces that are next to each other on the model, so when it comes to painting, you have a nice continuous flow between those faces on the texture. Which means, for instance, you can have signs and text and so on that don't just sit within a single face - they can wrap round corners, over the top of a roof, and so on.

The "exploded" faces kind of template we're talking about here is usually what you get from using an automated tool... it's very wasteful of texture space, which is the other problem.

Anyway, it looks like it's mostly working. Those logs look nice jaye. Where are the errors you mention?
f

[Jayecifer]

Some faces where not represented in the uvmap. So there are parts that just pull the texture across from adjacent faces... tops of the steps, sides of the saw turbines, end of the building that I cropped out. lol.

[fhko]

Did you actually sort out those faces to the planks around the log stack?...I just clustered them together hoping you'd pick some random solid color for them...

Did it turn out that some of the faces were mapped upside-down/backwards?...I haven't really figured out how to tell the orientation of a face using Lithunwrap...which I only have because I needed it for the model conversion process...

You know, we should have more threads like this. Where we all sit around and help a nice model through to it's completion.

I'll take that as a compliment...and I do have a second model that's complete...on second thought...I should probably add something more to it...

[Fooli]

I've been doing some research into Gmax and its related tools... I used to use 3ds Max v4, many years ago, and Gmax is basically the same as that. Its main restrictions are on import and export capability, as I'm sure you've discovered.

Anyway, the point is... while that means most Max plugins won't work with Gmax, most Max scripts will. And one of those scripts just happens to be Chilliskinner. Which is a pretty advanced unwrapping tool, at least compared with the native unwrapping tools in Gmax.

I shall sort out some kind of tutorial to aid future modelling efforts....

f

[Jayecifer]

The best way in lithunwrap is to pull open the model preveiw window. It will highlight what you have selected on the actual model itself.