|
|
| Post Number: 21
|
kat 
Admin
Group: Admin
Posts: 1325
Joined: May 2006
|
 |
Posted on: Oct. 13 2006,21:19 |
|
   |
Vertex Painting
Where ever you want a set of textures to blend together - ground blending to grass for example - a mesh need to have vertex painting applied to it.
The 'trick', if it can be called that, is to have a 'common' texture that's used as a blend with several other 'main' textures; in this case 'rock' and 'ground', both of which blend to a 'dirt' texture. Where ever the mesh has black painted vertices one texture gets applied; where ever there is 'white' the other is applied.
For more details on this read the texture blending tutorial here.
So in the shot below the vertex painting has been doen so that the 'dirt' texture will be the common material between both sets. You'll want to make sure that when you UVW map the objects that where possible both ground and rock surfaces are UVWmapped together.
The reason for this is so that the textures align properly to each other when the blending happens which makes seams in the mesh less noticable. Speaking of which, always try to 'hide' seams or mesh splits in areas that you'd naturally expect to see a hard edge as this makes seeing a seam more 'beleavable' when it is seen by the player.
Design Note : If you looking at this and NOT editing any id tech games then you need to look into how the game you're editing 'blends' textures, or if it does indeed do that; a fair number of games UVWmap unique textures to models so the image itself will have the blended transition from one type of image to the other.
Edited by kat on Mar. 06 2007,18:42
--------------
Admin
|
 |
|
|
| Post Number: 22
|
kat
Admin
Group: Admin
Posts: 1325
Joined: May 2006
|
 |
Posted on: Oct. 17 2006,06:00 |
|
 |
Model Collision
Once the main feature objects have been placed some work can begin on adding collision to the models.
Although models like the steps shown below can be left 'as is' for the game to work out collision (based on the data 'compiled' to the *.cm file), it's generally better to add a collision 'hull' over the object to keep things 'optimised' (read that as 'simple'). The collision model is usually a fairly basic shape relative to the parent object (the wonky, broken steps in this instance) which approximates the general contours and shape of the parent mesh as closely as possible.
The main reason for doing the collision as a model is that it's often very difficult to shape brushes to 'fit' models when they have been manipulated so the lines, faces and profiles of the mesh no longer fit Radiants grid, often with the result that brushes break, or that players get stuck on tiny none-visible edges where brushes don't match up exactly.
There is a second reason for doing collision on certain things like this; for some reason brushes covered in any of the various 'clip' materials - weaponClip, playerClip and so on - often react inconsistently with copious amounts of modelled geometry resulting in the player being able to jump through the models and occasionally through caulk brushes and out into the void. Modelling collision hulls doesn't fix the problem completely but it does appear to reduce it better than using clip brushes.
Raw modelled steps
The steps, as with everything else so far, were modelled from a template object converted a BSP file to an ASE model and then imported into Blender. As with the main map structure the template acts as a guide to shape the steps from. Also at this point it's worth noting that the leading edge of each step has been 'bevelled' to stop it from causing bad shadow problem in game due to smooth groups
The image below shows the original template duplicated and UVWmapped with a 'collision' place holder image. The material file for the steps in game will have the surface parameter "nonsolid" - this will allow weapon fire and/or player movement to 'pass through' the any surface marked as such - which is why the collision model is needed.
Shown below is the simple collision model itself. Because this is a collision model for a map object it can be a little more complex than the same sort of thing on weapons and entities, those can't exceed a given number of triangles, using 'standard' step height/width here means physics are 'normalised' - what you'd expect if running up a flight of stairs made from brushwork.
As can be seen for the image below it's nothing more than a 'skin' rather than a 'volume', as would be the case if it were a brush.
Edited by kat on Mar. 06 2007,18:43
--------------
Admin
|
|
|
|
| Post Number: 23
|
Silicone_Milk
Group: Member *
Posts: 390
Joined: May 2006
|
|
Posted on: Oct. 17 2006,15:28 |
|
|
Wow seems like you've been working a lot with blender lately. Everytime I come back to the forum it appears you've learned something new regarding the program and making models for Q3 =)
This is all very interesting and I'll be sure to come back to this thread once I get my main computer back online.
Excellent work so far Kat. I like the way this is unfolding :thumbsup:
|
|
|
|
| Post Number: 24
|
ratty redemption
"understood..."
Group: Member *
Posts: 1351
Joined: Sep. 2006
|
|
Posted on: Oct. 17 2006,17:12 |
|
|
I agree, very cool stuff kat, especially the tips on using collision models 
have you tested them in d3 to see if they work the same as in q4?
|
|
|
|
| Post Number: 25
|
kat
Admin
Group: Admin
Posts: 1325
Joined: May 2006
|
|
Posted on: Oct. 17 2006,17:26 |
|
|
Not extensively tested in D3 with this particular model, no, but models do exhibit the same collision problems in D3 as well as Q4 from what I've seen based on what I've been doing with other models.
That Abbey Cloisters model in the other thread has collision issues because I've not used the collision models at all in that one yet so steps are incredibly frustrating to navigate (Bob constantly gets stuck on them despite their being 'standard' height objects).
So yes D3 has problems with extensive use of models and collision.
@ Silicon : ;o)
--------------
Admin
|
|
|
|
| Post Number: 26
|
ratty redemption
"understood..."
Group: Member *
Posts: 1351
Joined: Sep. 2006
|
|
Posted on: Oct. 17 2006,17:48 |
|
|
thanks but I actually ment whether the collision models work as well in d3 and q4?
|
|
|
|
| Post Number: 27
|
kat
Admin
Group: Admin
Posts: 1325
Joined: May 2006
|
|
Posted on: Oct. 17 2006,19:07 |
|
|
Yes they do. Same engine, same model code, same (although tweaked in Q4) collision code.
--------------
Admin
|
|
|
|
| Post Number: 28
|
ratty redemption
"understood..."
Group: Member *
Posts: 1351
Joined: Sep. 2006
|
|
Posted on: Oct. 17 2006,19:11 |
|
|
ok, cool
|
|
|
|
| Post Number: 29
|
kat
Admin
Group: Admin
Posts: 1325
Joined: May 2006
|
|
Posted on: Oct. 19 2006,04:56 |
|
|
Player Size
In terms of the information covered so far in this topic this should be done as part of the initial stage of production rather than using them now (relative to this topics development history); player size templates.
Although player models have various sizes and proportions, which differ from game to game (Q4 is slightly larger than Q3 for example), it's always a good idea to have some sort of physical representation present in the level as you model so you can check your general environment proportions in relation to the players width and height; this saves having to go back and readjust elements of the model later on once you start running around only to find out that you can't actually fit through that gap in the wall you intended (eat fewer donuts Ed.) as a shortcut to another area.
The simplest thing to do is to load a player character into Radiant and place a brush over it (can be the actual model or the editors entity block) so that it covers the general proportions and then export that to OBJ or convert to ASE as previously mentioned. If the actual unit proportions of the player character are known then use those to draw out the template.
Once this template is in Blender it can be duplicated and placed at strategic points to act as a constant reference for size. It doesn't need to be textured because it's nothing more than a 'helper' and won't be exported as part of the level.
Edited by kat on Mar. 06 2007,18:44
--------------
Admin
|
|
|
|
| Post Number: 30
|
Silicone_Milk
Group: Member *
Posts: 390
Joined: May 2006
|
|
Posted on: Oct. 19 2006,06:00 |
|
|
I did the same thing when using GTKRadiant 1.4 to build a Half-Life 2 map.
The player entity size in CS is about 16 quake units higher than the 64 unit high entity in the Q3 engine.
Some good advice here. I think I need to make a signature for my accounts on other forums and give this place a little more publicity ;)
|
|
|
|
|
|
