Modular modeling – a quick example

[Bikerdude]

If you rotate using the right mouse button, it rotates around the origin. If you use the left, it rotates around some abstract point behind the camera

 

@Fingernail, Blast from the past. How are you doing Finger?

 

Ta, will check.

 

+1

[peter_spy]

I think you're right there.

 

The only savings on Brushes is BSP culling which (in this engine) is very conservative.

 

 

Edit:

 

 

 

https://www.iddevnet.com/quake4/LevelEditor_Performance

 

So it seems that all brush-work of the same texture, touched by the same light, in the same portal area should be one draw.

Of course, "same texture" is a very strict term which only applies to a texture tiled over the geometry with the same UV and scale,

hence how shifting textures ( brush carving ) can be used to split brushes at light boundaries.

 

And then, with brushes, everything is dynamically generated per PVS view which seems to make them heavier in most scenes compared

to the same scene with lots of proper func_statics or models.

 

 

Good find, I also just found this: https://simonschreibt.de/gat/renderhell/ but that requires a longer reading session. All in all, industry moved away from brushes almost completely, using it only in prototyping stages. In UE3/UDK and later engines you can have your level geometry built entirely out of static meshes.

[peter_spy]

On somewhat related note, the way this engine handles parallel mesh surfaces is amazing. Typically you need two adjacent mesh walls to use some kind of angle, because you'd see dots or shadowing problems where the two mesh edges meet. Not in idtech4:

 

 

Meanwhile in UDK:

[RPGista]

Thank you for the tutorial, its always great to see someone put in the work to benefit the whole community. I would consider making this a wiki article, so it wont eventually get buried inside the forum. As for the model itself, the material and texture look quite good, but I agree with those who say that scene budgeting is a mapper's responsability, and that individual models (modular or not) should obviously be rational, but the trade off must always be on the side of style and art. In your example, the trims for example, should have been kept as the high poly model version, while only the panels should be simplified. Thats because the attention, when modeling, should be to focus care on the profile of the objects. And a simple sloped surface just wont do when the player looks at one of the wood panel corners. As springs said, the trouble with performance begins when you start adding AI to the game, and lights. But most problems can and should be solved by good visportals, cutting the map into confortable pieces the machine can handle fine. Also, by making your models no shadow, you can take them out of the equation pretty much. You can save your prefab with a very simple shadow mesh inside, to cover for any scenario.

Edited April 19, 2017 by RPGista

[Destined]

 

 

When I saw the bottom picture, I had to smile a bit, as the models do not align. As it turns out, this can even happen in AAA games

[Melan]

AAA games? Look at the carpentry in some IRL houses!

[Springheel]

When I saw the bottom picture, I had to smile a bit, as the models do not align. As it turns out, this can even happen in AAA games

 

 

When I was doing research for my models (primarily Thief and Dishonored) I saw this all over the place.

[HMart]

The polygon count for your modules are too low. With matching textures, the scenes depicted could easily be recreated with a few brushes and the clipping tool.

 

It's important to note that TDM uses a forward renderer. For each light, for each entity, render a pass. Every module in view is going to get a separate draw call. And if you're incurring the penalty of a draw call and not throwing a considerable number of polygons at the GPU, you're not getting your money's worth.

 

I recommend beveling a few of the hard edges and making use of smooth shading.

 

You are totally right but imo you are forgetting a important fact, TDM engine uses stencil shadows, the more polys you give a model the heavier it becomes to calculate the shadows, if you don't want to be forced to make a shadow mesh for all modules, is best to be careful with polys, is all a balancing act but i recommend anyone making models for TDM to do this, for unique models use the necessary poly's to preserve the shape and make it look good, if necessary make a shadow mesh, for modules that will be cloned many many times, like walls and have the potencial to be rendered also many times on a single scene or frame, save on the poly's, use normal maps the most you can.

 

Btw even tho afaik no one uses POM (parallax occlusion mapping) on TDM, tho i think the engine interaction shader supports it, is always better to use real geometry because GPU's are faster at rendering triangles than they are at rendering pixels (shaders), specially ray traced pixels.

[peter_spy]

Thank you for the tutorial, its always great to see someone put in the work to benefit the whole community. I would consider making this a wiki article, so it wont eventually get buried inside the forum. As for the model itself, the material and texture look quite good, but I agree with those who say that scene budgeting is a mapper's responsability, and that individual models (modular or not) should obviously be rational, but the trade off must always be on the side of style and art. In your example, the trims for example, should have been kept as the high poly model version, while only the panels should be simplified. Thats because the attention, when modeling, should be to focus care on the profile of the objects. And a simple sloped surface just wont do when the player looks at one of the wood panel corners. As springs said, the trouble with performance begins when you start adding AI to the game, and lights. But most problems can and should be solved by good visportals, cutting the map into confortable pieces the machine can handle fine. Also, by making your models no shadow, you can take them out of the equation pretty much. You can save your prefab with a very simple shadow mesh inside, to cover for any scenario.

 

Thanks for the kind words. You're right about the model, of course. At first I was thinking about giving the middle section some more depth, while it's the trims that will look better with some more polygons and variety in angles. Also, it's the fastest and easiest way to improve the look of the model, while it still will be very low-poly. There's no need to keep the higher-poly version of those trims, especially that this shape has polygons that are 1 or 2 units wide. Without proper texture they'd look almost invisible anyway. And, you can easily fake it with proper diffuse and normal textures, and just get something in-between on geometry level. The goal is to keep a healthy relationship between mesh shape and final (possibly just one) material, so the overhead can go for other uses, like AI, physics and such. I've been using the r_showtris command a lot lately, it's been very useful for studying both meshes and brushes. Also, I have my autoexec.cfg with seta image_downSize command ready, so I can see how the artwork holds up when scaled down for optimisation. I must say I'm quite pleased with the results

 

 

 

When I saw the bottom picture, I had to smile a bit, as the models do not align. As it turns out, this can even happen in AAA games

 

Well, that's not the worst thing I've seen lately, take a look at this:

 

"You think anyone will notice?" "Nah, leave it."

[Destined]

I think I am too critical with my own work and should trade (at least some) cleanliness for speed...

[peter_spy]

Healthy criticism is fine. You just need to know when to stop refining your work, because at some point it's diminishing returns. It's important to take breaks or ask for feedback, because that really contributes to quality of your work. I see that especially with textures and materials, the first version is rarely good. 3rd, 4th iteration is where I can say: "now we're talking!".

 

I don't think speed should be a relevant factor in modelling until you're confident with your skills, when you know your workflow is solid, but could be improved. Actually, speed and ease of use is more important while placing models in your map, so it's better to spend a few extra hours on careful planing in that department, especially if you want to release your models to the public.

[Obsttorte]

When I saw the bottom picture, I had to smile a bit, as the models do not align. As it turns out, this can even happen in AAA games

 

 

When I was doing research for my models (primarily Thief and Dishonored) I saw this all over the place.

This could also have been done on purpose. If the trim on the wall and the pillar would end up at the same height you would get z-fighting.

[peter_spy]

A small update: slightly reworked trims made big difference without raising triangle count too much. Straight modules have 26 triangles, corners are joint together now to decrease unnecessary extra drawcall for left and right side, so they have a bit more, but still, 127 triangles is nothing these days

 

 

[Bikerdude]

If you rotate using the right mouse button, it rotates around the origin. If you use the left, it rotates around some abstract point behind the camera

Ta, will check.

So had a look at this and found what I was doing,

• right click stays toggled on when clicked, which Im sure it didnt do in 1.8.1 (so will raise a tracker for that)
• Left click as you said rotates it on the spot and it dosent toggle like the above.

Also, cons you or some one confirm if right click used to be the way you rotated items on the spot in the inspector..?

[Bikerdude]

Very nice work their Judith.

[Destined]

 

This could also have been done on purpose. If the trim on the wall and the pillar would end up at the same height you would get z-fighting.

Yes, you are correct. Found an instance in Addermire Institute, where exactly this happened.

[Fingernail]

Looking great now Judith - even better!