Jump to content
The Dark Mod Forums

Static Modelling


_Atti_

Recommended Posts

thanks for the comments!

@_Atti_: I started with generic marketstalls. Specialized ones will be on the way

@Baddcogg: I tried to keep the polycount as low as possible because I'm trying to put some vegetables and other stuff on the shelves. Even if they are not detailed are quite poly expensive.

@RPGista: thanks for the links and tips! The actual assets are "copied" from a medieval market photo.

 

Unfortunately I'm facing some problems with material mtr files. I don't know how to make a customized mtr for the darkmod. I opened a mtr file but seems like there's some extra text compared to doom3 and I don't know what is it (ambientlight stuff). Is there a sample mtr with diffuse,normal,spec?

Link to comment
Share on other sites

I hear ya, but the polys really don't impact the engine much at all. The thing that really has a hit is shadow casting tris with multiple light sources on them. So a model with 5000 tris and 2 light sources is gonna have less impact than a 1 tri model with 6 lights...

 

Authors have the deal with that in all respects of mapping, so having a really low poly model doesn't matter.

-------

 

Still, you need to optimize the model 2 ways. 1 is a shadow mesh. Basically you could use what you have, place shadow tex on it. then put it inside a higher poly model. Then it's just as optimized but looks a lot better.

Another is a collision mesh, which isn't as big a deal, but if things are thrown/bounce it takes fewer calculations. Use the same low poly and put collision tex on it.

 

just stack all three models on top of each other and export as one file.

 

Then there is also the fact that we have LOD's now. So the model can look great up close, but get lower poly at distance to save more performance.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Hi! Thanks for the help and tips! I'm back to show some progress, so far I made this:

20f5nbp.jpg

 

svjix2.jpg

 

mkwy7b.jpg

 

I think I have to remove the collision map in the cart, crates on the marketstall, and make some vegetables to add variation.

 

I'd like to know something more about lod. Is there a specific workflow?

Link to comment
Share on other sites

I don't think there's any 'required' workflow for LOD. Usually it's easier to make the higher poly model and uv it good, then break that down into lower poly versions by collapsing verts and keeping uv seams intact (then you don't have to touch-up/re-uv. But say the market stall, if you are using 4 sided boards, then you can select the edges and chamfer them to make them a bit rounder egded and the uv's should stay intact.

 

So you can go up or down with polys with not much more work, just takes a little practice. These days i prefer to work on my higher poly first, because it's the one seen up close and I want it to look best. The broken down models don't have to look as good as they'll be seen from further away. So if they get a little 'rough' in the process it's ok.

 

---------

Collision models work 2 ways in this engine.

 

1: moveables. Things player can grab and move around. They HAVE to be convex and have a limit of like 16 polys. So they trays on the market stall would have to be just a cube. So things either float or clip through the edge pieces...

 

2: static objects. These can be concave, so you can make a bowl shape for the market stall pieces. Basically you're just simplifying the shapes. For the kart the wheel collision could be a 7 sided cylinder. The major issue would be arrows sticking in the air between the spokes... but how often will someone be sniping through those wheels...

On the other hand, collision meshes aren't that big of a deal for stuff like this... It's not like stuff will be bouncing off of them all the time, and that's the only time is matters.

 

* some things don't need to be moveable anyway. Like the coin stacks.

(authors could still stack single coins and make a moveable def...). But if a fire arrow goes off nearby stuff scatters to all edges of the map for example.

And what if someone picks up the broccoli tray, turns it upside down, nothing falls off...

So some things are best not moveable. But still a simple 'blob' collision over it would be good in case someone drops a cup on top...

 

If you did want it moveable just make the tray as one object (I think we have wood cutting board) and make one piece of broccoli. Then pile them up in editor and save as a prefab so authors can drop in one quick ready to go broccoli collision nightmare ;)

 

---------

Keep in mind too. Having a shadow/collision mesh with your object does NOT fix the shadow/collision properties of the used materials. So if you have a shadow mesh for the market stall you need to use a NoShadows texture for the wood. Or you're just adding shadow casting and making performance worse.

 

I added _ns to the ends of all our stock materials that I have used in models. So use them on models with shadow meshes. Or add NoShadows and NoSelfShadow (or is it noshadow noselfshadows? - one is plural on is not) to your textures.

 

The broccoli could probably be noshadows at all, but an author can always add that tag anyway. But they definitely don't need self shadows.

 

----------

 

And since I can't see your wireframes...

 

The engine uses vert lighting. So on larger items like the cart and awning it looks much better if you add extra polys. The top of the awning could easily be 2 tris, but it'll light horribly. If you make it 8 tris it will look much better, the shading/lighting will be much smoother.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

@Baddcog: thanks for the vertex lighting tips, I surely have to fix some vertices/loop. Is it possible to use pre-painted vertex colours? I tried the vertexcolor in the mtr but in-editor the texture switches to notfound

 

@_Atti: thanks! No game in game shots, I'm sorry I can't dmap, probably it's an administrator - programs folder issue in vista... I really hate this OS!

Link to comment
Share on other sites

Yeah, I would recommend re-installing Doom3 and TDM on a "Games" or some such folder OUTSIDE the "Program Files" default one, as it is the most protected. Right click on the Doom3 exe later and check the admin rights on it. The whole thing really is a pain, and has kept me wondering many times why things dont work well (specially on older programs and games).

Link to comment
Share on other sites

vert colors can be used for blends at least. I think there's a tut on the wiki for that (making ground paths with blended dirt/grass).

 

However that's only using black/white.

 

You can also use blends and modulates to say blend a gold metal over an AO. I messed with it for awhile but it can be hard to get good results.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

I can't still get the cart in a map, I re-installed doom3 in a different directory (C:\doom3) and reinstalled darkradiant too, I made a simple empty room to see how the model looks like. After dmap and map the model isn't in the map. The room is fine (texture and lighting), the cart has only collision and it's invisible. what's wrong?

Link to comment
Share on other sites

thanks atti, unfortunately doesn't seem to be this problem, the ase it's already pointing to the right mtr... I really don't know what's causing this problem, I think I'll upload the progress i made so far so others can check what's wrong

 

here's the link:

http://www.2shared.com/file/gYU8Ce4g/tdm_market_assets.html

it's a pk4 and should be placed in the doom3/darkmod/ folder (where all other darkmod's pk4s already are)

Link to comment
Share on other sites

The engine uses vert lighting. So on larger items like the cart and awning it looks much better if you add extra polys. The top of the awning could easily be 2 tris, but it'll light horribly. If you make it 8 tris it will look much better, the shading/lighting will be much smoother.

 

Lighting is actually calculated per-pixel, but vertex normals are used for smoothing, which I suspect is what you are referring to. If an object contains a few large polygons with a large angle between them (e.g. a six-face cube with 90° sides), the default smoothing can make the shading look very ugly because the engine is really trying to smooth your cube into a sphere, with obviously poor results.

 

There are in fact three possible ways to address this:

  1. Increase the polycount, as you suggested. You don't necessarily need to increase it across the entire model, just around areas with a large change of angle. So your cube could have a big flat square in the middle of each face and lots of subdivided rectangles towards the edges so that the angle between any two polygons was relatively small.
  2. Separate joins between faces (by duplicating vertices) where you don't want any smoothing to take place over that edge.
  3. Try using the "unsmoothedTangents" material keyword, which seems to reduce the poor shading without turning off smoothing entirely.

Link to comment
Share on other sites

You sure about that? Maybe the terrain is lit by pixel, but the models are most definitely lit by verts.

 

I know how to make hard edges, you gotta split the edge. That's NOT what I'm refering to, I'm quite well aware of what vert lighting is and the effects it causes.

 

Take for example the timber beds. I had a few large polys as the top (as that's all that was required for the shape), But what happened (as is the case with vert lighting) is that if the vert in one corner of the bed (they did have beveled round edges) was not lit, then there would be a very large black triangle across the top of the bed. Since it is shading from the unlit vert to the two lit verts at the other corners of the triangle.

By increasing the number of verts across the top of the bed that single unlit vert makes a much smaller triangle of shading in the one corner, with much more of the beds verts falling into light the shading is much smoother.

 

I posted pics somewhere... Though I'm not going to dig for them.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

I think what Baddcog says if you have two verts (a single tris) along a face, and one corner is hit by the light (100% light) and the other not (0% light), then the engine will linearily interpolate, creating a 100..0 ramp. However, due to the lights ussualy not having a linear falloff, the middle of the bed would incorrectly get 50% light. If you add a few more tris, the ramp is much smoother and actually more in line with the light falloff, which would f.i. 30% at the middle of the face instead of 50%.

 

Edit: Beveled edges and corner-cases (e.g. one very accidentily being in shadow) creating other artefacts is also to consider. Having a few more tris for a flat plane reduces these artefacts.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

You sure about that? Maybe the terrain is lit by pixel, but the models are most definitely lit by verts.

 

Yep, 100% sure. Id Tech 3 uses a unified renderer with per-pixel lighting; that was one of its big selling points (at the time). There was even an article I saw by a developer at Id describing the advantages of such an engine over the vertex lighting and light maps of previous engines, and specifically the ability to light models and map geometry in the exact same way. It would be difficult or impossible to implement things like projected light textures and dynamic bump mapping if the lighting wasn't calculated per pixel.

 

Take for example the timber beds. I had a few large polys as the top (as that's all that was required for the shape), But what happened (as is the case with vert lighting) is that if the vert in one corner of the bed (they did have beveled round edges) was not lit, then there would be a very large black triangle across the top of the bed. Since it is shading from the unlit vert to the two lit verts at the other corners of the triangle.

 

That is the same smoothing issue I was referring to. The normal is calculated per vertex, smoothed over too large an area and then used as input for the per-pixel lighting calculation, which results in that incorrect shading.

 

In any case, the distinction between per-vertex lighting and per-vertex smoothing used as input for per-pixel lighting is probably splitting hairs and irrelevant from a mapper's point of view, since the solutions (increase polycount, split faces or use unsmoothedTangents) are the same anyway. It might also be affected by the format (ASE or LWO) used to export the model: I have heard that the LWO format allows more control over the vertex and face normals used by Doom 3, whereas ASE is just totally smoothed unless faces are split.

Link to comment
Share on other sites

It might also be affected by the format (ASE or LWO) used to export the model: I have heard that the LWO format allows more control over the vertex and face normals used by Doom 3, whereas ASE is just totally smoothed unless faces are split.

 

Yes, this appears to be the case...the issue baddcog is describing (as well as another issue of smoothing pointed tips) has never been a problem for me using LW.

Link to comment
Share on other sites

If there is no normalmap present ( or a "flat" one is used ), the surface-shading will essentially be based on the directions of the vertex normals.

 

The interaction.vfp still does this shading per-pixel tho, even if it ends up looking like it's just vertex-shading - because the vertex-normals are used to transform a normal-map( which may be a "flat" one if none is defined in the material ) into tangent-space for the lighting calculation.

 

If you have baked a dedicated normal-map from a high-poly model onto the ingame-mesh, it will look more like you would expect "per pixel shading" to look, because the baking process takes the low-poly vertex-normals into account and "compensates" for them.

 

@Orbweaver :

I believe only MD5 requires you to actually split faces to get hard edge-shading, because the file format has no support for vertex-normal information.

ASE and LWO do however, but it highly depends on the exporter used. The Unreal ASE axmesh exporter for Maya writes this information properly iirc.

Link to comment
Share on other sites

Well, however it works exactly the shading is the same as vert lighting when it comes to polycount. very low counts on large flat planes can give very crappy results. upping the mesh density makes it look much better.

 

The beds I made had normal maps, but they weren't object specific, they were existing materials. ie: blanket and timber wood.

 

---

With the Max ase exporter you HAVE to split the edges if you want them to be hard, otherwise they all get one smoothing group in game.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

  • 7 months later...

Thanks for the comments, will export these then if i come around a comp with Radiant.

Made a table that goes with the chair. Ornaments are on different Map so they may be replaced with the same texture as the rest of the object uses or some other symbol. Cushion also on different map, so also skinnable.

 

Table is 763 tris. Didnt want those curves to be too jagged.

post-73-0-60438000-1341229084_thumb.jpg

Edited by _Atti_
  • Like 4
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...