Jump to content
The Dark Mod Forums

Making LOD models


Tels

Recommended Posts

So it's better to have to dig more and have more confusion over a few lod models then just have them organized with regular models?

 

Seriously, another directory is about enough to make me say screw it, NO LOD's from me. I can make a model and texture in an hour but it takes two to get everything in the correct places and troubleshoot. Why make that harder?

 

But whatever, all we need LOD's for is stuff at long view distances (aka outside vegetation mostly), so why bother doing it at all, I don't plan to make any forest FM's anyway.

 

I believe in having organization as much as anyone, but at a certian point you are just shooting yourself in the foot. Creating MORE folders is that shot in the foot.

 

You can clearly see by any of my posts in the LOD topics that I'm not all that hot on the idea anyway. But if it's just going to make modelling harder then I see no point whatsoever. Makes it harder for no reason = less fun= less motivation = less modelling. And for what? to keep 20 models seperate?

 

-------

And I'm not saying this lightly. Believe me, I go through this daily at work.

 

When I started here we had 1 folder for all jobs on the server. The boss would try to show me a file and it would take 20 minutes for all the files to load so he could see the T's.

So I suggested we organize the folder and add more folders.

'but that'll be too long to find... blah blah', finally OK but don't make too many.

So I made A-Z folders and lo and behold, we could now access those same files in 20 seconds intead of minutes.

So I proposed that large clients get their own folders... with trepedation the boss said OK, but not too many...

And everything was easy to find... until the boss decided to add a new folder for every single job.

Now instead of 200 folders we have 2000 on the server and it's a royal pain in the ass to find anything.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

  • Replies 51
  • Created
  • Last Reply

Top Posters In This Topic

So it's better to have to dig more and have more confusion over a few lod models then just have them organized with regular models?

 

Seriously, another directory is about enough to make me say screw it, NO LOD's from me. I can make a model and texture in an hour but it takes two to get everything in the correct places and troubleshoot. Why make that harder?

 

I am sorry that you feel that way, but as I said, the decision should be to make the life of the mapper easier first, then the life of the modeller. We have many more mappers than modellers, and models are selected many times more than created.

 

However, as I also said, nothing is decided yet (and I am undecided myself in any event).

 

But whatever, all we need LOD's for is stuff at long view distances (aka outside vegetation mostly), so why bother doing it at all, I don't plan to make any forest FM's anyway.

 

Well, yeah, I we all have gotten your point by now - you don't need LOD because you don't plan on using it ;)

 

But, you can only speak for yourself - other people will use it and will need it - even if it is myself only :)

 

You can clearly see by any of my posts in the LOD topics that I'm not all that hot on the idea anyway. But if it's just going to make modelling harder then I see no point whatsoever. Makes it harder for no reason = less fun= less motivation = less modelling. And for what? to keep 20 models seperate?

 

Nobody forces you to do any LOD models whatsover. ;) If you do the originals (which you are good at!), somebody else will take care of the rest. So please don't get upset, just continue modeling and the other people will take care of LOD for you. Does that sound like an agreement to you?

"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

Seriously, another directory is about enough to make me say screw it, NO LOD's from me. I can make a model and texture in an hour but it takes two to get everything in the correct places and troubleshoot. Why make that harder?

 

If it's that taxing for you to find which folder to save a model in, send them to me and I'll take care of it. It takes me about twenty seconds.

Link to comment
Share on other sites

Interesting discussion. I urge everyone to keep their cool.

 

If I'm understanding this correctly, we are going to have intelligent model-entites, which switch the model depending on the distance to the player. So the mapper chooses this entity and no longer the models from the models-list?

 

The mapper is going to access the model listing more seldom so it's more important to have the entitylist in perfect order.

 

If the mapper is placing a static model, I suppose it's most likely the real-model. Manual placing of LOD models would probably be somewhat rare. Therefore it would be rather tedious to have the LOD models in the same list as the real models.

 

Is there any performance drain for the entity checking it's distance from the player? I'm trying to grasp the magnitude of this thing: will even all simplest objects be LODified in the future. Even a basic cooking pan and other objects would have the LOD entity placed rather than the simple static model? Or is the system saved for only outside vegetation etc.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Interesting discussion. I urge everyone to keep their cool.

 

If I'm understanding this correctly, we are going to have intelligent model-entites, which switch the model depending on the distance to the player. So the mapper chooses this entity and no longer the models from the models-list?

 

That's the plan. It was supposed to be a secret untl release, tho :)

 

The mapper is going to access the model listing more seldom so it's more important to have the entitylist in perfect order.

 

Yep. However, all the LOD entities are currently in their own folder, "Nature", and "Statues" because that are basically the only entities we already have LOD models for.

 

If the mapper is placing a static model, I suppose it's most likely the real-model. Manual placing of LOD models would probably be somewhat rare. Therefore it would be rather tedious to have the LOD models in the same list as the real models.

 

Yeah, I think this is why SH wants them in their own folder.

 

Is there any performance drain for the entity checking it's distance from the player?

 

About 7% for 3000 entities, and 10% for about 5000 entities. However, that is their "thinking", the distance check is done way more seldom and probably just a small part of this. Plus, you really don't want to have 5000 entities in your map, trust me :)

 

I'm trying to grasp the magnitude of this thing: will even all simplest objects be LODified in the future. Even a basic cooking pan and other objects would have the LOD entity placed rather than the simple static model? Or is the system saved for only outside vegetation etc.

 

It is mainly for objects where the benefits are there. No need to reduce a cooking pan from 36 tris to 24 tris, when you can reduce a bush from 150 tris down to 4 or a cattail from 330 to 4, or a statue from 3000 down to 500 :) Also, objects that are there only once benefit way less than things like vegetation that get sprayed everywhere. Likewise for rocks, any other decoration etc.

 

Plus, there is another plan, but I am not supposed to tell you :)

"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

I'm perfectly calm just so everyone understands. So take the condesending crap and shove it... lol. Butt seriously.

 

I've said what I said and stand by it. If you guys want things to be harder to do then go ahead. Hopefully anyone who decides to make models in the future feels like that's a good decision too. Because as it is the 2 or 3 people who have tried have had a major pain in the ass time getting models to work as is learning the ins and outs (and that's with us helping), I'm sure they won't mind one more obstacle to get there. That can only make people want to do it more.

 

One thing I think you guys don't understand is we're hoping to have more and more people come over from T2. In T2 you had

Thief II/models/

and

Thief II/models/txt 16

 

That was it, make a model and tex, throw it in two folders no more than 2 deep. Done. Now we want those modelers to come over and contribute (while they learn alot of stuff about normals, specular, defs, shaders, why dds are here, tga are there, what entities are, lod models, and now also another path of why are models here and lod's there...). And then to map they have to KNOW where entities are with LOD's with no clue that those LOD's are included?

 

I've already showed partial paths above and it's 10 x more complex just to get a model in game. Lets make that 11x, Spinal Tap style YEAH! Nothings worth doing if it isn't done the hard way.

 

And no, I'm not going to send you LOD models to 'save' (?) time by not digging more. I'm just not going to dig. How can I test and work out bugs if I don't place the LOD's to begin with?

 

Why don't we bury the LOD code in 20 folders deep, just so the coders have to dig that much more anytime they want to work on it. Makes no sense does it? Can we put defs for LOD models in a seperate folder from the regular defs just to... I don't know, just to do it I guess.

 

And how does it make it any harder on mappers to see a few LOD models listed among the regular models. If we follow a naming convention they'll be perfectly understandable by even the most dim whitted Taffer (Benny) around. And as I pointed out above, it'll actually make it easier for them to tell WHICH MODELS HAVE LOD without digging through the entities list.

 

But I regress, I model AND map less than you guys so what the hell do I know?

 

The way I see it is we have at most 3 people working on this.

 

Tels on LOD scripting, and 'decal models', I was going to try and get some more 'serious' (3d) models (multiple stages) working, and possibly Spring has/will do some LOD's ?

And I don't want to deal with some assanine folder structure just so mappers don't have to see a few 'lod's' here and there IF they are in the model browser (including myself). So if we go that route and I don't want the extra trouble that's down to Tel's and Spring. Tel's is busy with coding and Spring is busy with AI.

chirp chirp... LOD is DEAD.

 

If I thought it was going to make mapping harder would I want to do it? That's making it harder on myself too.

 

----

@Sotha,

 

The entity list won't be cleaner no matter where the models are. The 'viewed' folder of entities is decribed in their def file. So they could be in Doom folder and appear in darkmod/models/kitchen/underwear if you want . The entity list really mimics the Dark engines heirchy, the model 'path' is not necessarily where it's located at.

 

And most objects don't even need LOD. Not like there's gonna be 4 models for every model.

Things like carrots could just 'disappear' after 500 units (you wont see them anyway).

Only things that will be seen at greater distances will need them, and as far as that goes most of our models aren't that high in polys anyway. So even lampposts don't really need them.

vegetation really is the best area for them, because it takes lots of trees, blades of grass, bushes to really make a thick and convincing scene. And they also leave space to see between/thru them.

 

And I seriously doubt that even if we planned to LOD everything that 1/4 of the current models would ever be done. I don't think people realize how many models we actually have, it's at least on par with T2 if not more. The only reason people have the impression that T2 might have more is because people like myself made hundred of objects through the years and everytime you seen one you go 'wow, a new custom object'. In TDM it's just 'Stock objects', people probably haven't even seen all of them in game yet.

And this is a detail oriented game so even if we had 5x the objects people would still want that one 'specific' object that we could never have guessed anyway.

But my point is there are tons of objects and only 2 people even working in that department atm, so new objects or rehash old objects?

 

There also is plenty of use for lower LOD models without using the LOD system. LOD I'm sure does have some overhead, so using it has overhead, and if someone is trying to get better performance lower LOD's can help. (hopefully they can look decent up close too for that reason).

So if you have large wide open spaces YES you want to use LOD and it's benefits will outway the drawbacks.

But if you don't have those areas it's gonna be a performance detractor (no matter how small). So in some cases just using a lower LOD is worth it.

 

LOD's probably shouldn't go into effect until at least 500 units so the switch isn't obvious. 1000 units is a pretty good distance to see IMO so most mappers won't be going much past that with most FM's if they want good performance. Things like shovels will be almost non-visible by that distance anyway, so if they are in a dark spot you can probably make them just vaish instead of swapping models.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

As it stands, the model previewer within the level editor displays all the models that are in the models folder. It doesn't make sense for a mapper to see the LOD models so if you choose to place them in the models folder you now need to come up with a way to filter out the LOD models from the list.

 

I don't think it's much trouble to use a separate LOD folder in the same way there is a separate DDS folder but as a compromise how about you just rename the extension of each successive LOD model. For instance, you can have the following files in the same location ...

 

mytree_01.lwo

mytree_01.1

mytree_01.2

mytree_01.3

 

It can be assumed that all the models use the same format as the original and yet because they are not named LWO, they will not show up in the models list. This solution should please everyone. DarkRadiant won't require any changes and no new folders need to be created. Thoughts?

Link to comment
Share on other sites

It can be assumed that all the models use the same format as the original and yet because they are not named LWO, they will not show up in the models list. This solution should please everyone. DarkRadiant won't require any changes and no new folders need to be created. Thoughts?

 

I'm no specialist in this field, but sounds simple and brilliant.

 

However, does this means that the mapper cannot manually choose LOD models? It's a rare occurence, yes, but might be useful at some situations like skybox backprops. Or if the mapper gives spawnarg "model mytree_01.1" instead of "model mytree_01.lwo" does it work?

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

As it stands, the model previewer within the level editor displays all the models that are in the models folder. It doesn't make sense for a mapper to see the LOD models

 

Er not quite. Placing these LOD models in a skybox is a good application. And it is definitely easier to place a model than to draw up a patch, apply the texture etc. Esp. in case where the LOD model is still quite simple, but consists of more than just two patches.

 

We could of case make prefabs, but making an LOD model AND a prefab of everything is a maintainance nightmare.

 

so if you choose to place them in the models folder you now need to come up with a way to filter out the LOD models from the list.

 

I think a simple toggle in DR that filters out anything named "*_lod_*" would be the easiest way.

 

I don't think it's much trouble to use a separate LOD folder in the same way there is a separate DDS folder but as a compromise how about you just rename the extension of each successive LOD model. For instance, you can have the following files in the same location ...

 

mytree_01.lwo

mytree_01.1

mytree_01.2

mytree_01.3

 

It can be assumed that all the models use the same format as the original and yet because they are not named LWO, they will not show up in the models list. This solution should please everyone. DarkRadiant won't require any changes and no new folders need to be created. Thoughts?

 

Bad idea, because you never could access such a model in DR again, not to name the other tools that expect ".lwo" or ".ase" files. (I am not even sure D3 could load these files). Let's please not even think about changing the extension.

"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

I'm perfectly calm just so everyone understands. So take the condesending crap and shove it... lol. Butt seriously.

 

*hides shovel behind back*

 

And I seriously doubt that even if we planned to LOD everything that 1/4 of the current models would ever be done.

 

Treu, I'd expect even less. Only objects which have at the same time:

 

* many tris and can still expressed simpler form afar

* are visible from far places

* are placed in high quantities

 

I don't think people realize how many models we actually have, it's at least on par with T2 if not more.

 

te@te:~/.doom3/darkmod_org$ find models|ack -v .svn |ack "(\.lwo|ase)"|wc
  1376    1383   68063

 

Over 1300, give or take a few because I might have a few testmodels in my tree.

 

LOD's probably shouldn't go into effect until at least 500 units so the switch isn't obvious. 1000 units is a pretty good distance to see IMO so most mappers won't be going much past that with most FM's if they want good performance. Things like shovels will be almost non-visible by that distance anyway, so if they are in a dark spot you can probably make them just vaish instead of swapping models.

 

Exactly. Tiny grass blades can even disappear from 300 units onwards, while a big tree needs to be visible even from 20000 units (or your forest will be invisible :) so having a LOD tree definitely helps.

 

Basically, the LOD system will make things possible that are simply not possible with the current technology. But it will rarely improve the existing missions (I have other stuff for that :) because most missions didn't have wide open spaces with lots of objects.

 

One thing that comes maybe to mind is adding "decoration" to missions, like grass in wet/dark city corners, statues high up on roofs etc. These would definitely benefit from the LOD system (either because they can be simply hidden, or because a gargoyle with say 1500 tris 50m overhead is overkill and could be easily just 50 tris :)

 

A good point of this is in one of the NHAT (I believe) missions, where there are courtyards and you have tons of statues high up with tons of polies. But as I said, this isn't exactly high-priority for me.

 

I am more the "jungle, jungle, jungle, baby!" man :D

"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

In cases where a specific level of detail is required why not add a key value pair for func_statics called "LOD" and you can set the value to whatever level you want to use?

 

The problem with that is that the LOD levels (or stages) do not nec. corrospond with the LOD models. Each func_static can have 7 different stages, but what model corrospons to what stage is total open. (not only this, but it is possible to change the total number of stages in code, in case we ever want more than 7)

 

E.g. some func_statics have 3 LOD levels (some statues), some vegetation have only 2 (original and simple) etc. So it would not be that simple to say "I want the model for stage X".

 

Also, it would mean that you see model X (the original) inside DR, but model Y (LOD stage whatever) in game, so the mapper always needs to check things in game just to judge how they look. That's very cumbersome, it is much faster to hit "add model", then select the appropriate low-res model in DR and place it in the skybox or the far background.

"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

Back to the topic at hand, making LOD models :)

 

I selected the lily model as my next target. It is actually even more usable for LOD because it has 981 polys in 3 surfaces, compared to the cattail, which has 337 polys in 1 surface. Yikes, that's a lot of detail for a small flower! :ph34r:

 

One word about drawcalls. Each surface for each model will issue one drawcall per light. That means if our lily model is hit by three lights (say "the ambient", "the foglight" and "some torch"), then you will have 3 * 3 drawcalls (3 lights * 3 surfaces), so this model alone will issue 9 drawcalls, and each of them will work on 981 * 2 = 1962 tris, which makes for a total of 17658 tris to process just for one model. Ouch! :o

 

(Don't get me wrong, if I am standing next to a lily in game, I want all the details I can get! But not when it is more than 2m away :)

 

So while making this model, I learned a few new tricks like how to:

 

* get the camera level

* deal best with skins

* deal with four sides instead of two (for more asymetric models)

* color-correct the texture atlas for a better match

* deal with the fact that one side has a different size than the others

 

I'll upload the pictures to the wiki and update the article next, I will post when it is done.

 

In the meanwhile, here are is an in-game screen:

 

post-144-12854124887_thumb.jpg

"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

Okay,

 

screens uploaded, lily-model/texture atlas/material and def comitted, and wiki updated:

 

http://wiki.thedarkmod.com/index.php?title=Creating_LOD_Models

"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

Now we want those modelers to come over and contribute (while they learn alot of stuff about normals, specular, defs, shaders, why dds are here, tga are there, what entities are, lod models, and now also another path of why are models here and lod's there...).

 

Modellers will have to learn about normals, speculars, defs, shaders, dds and tga regardless of where we put LOD models.

 

They don't need to know anything about entities to make models.

 

They don't need to know anything about LOD models, unless they're planning on making some.

 

IF they would like to make some LOD models, then they will need to know where to put them, obviously. How is this any different than knowing where to put any other model?

 

Where do I put this chair? Oh, it goes in furniture/seating? Thanks. Where do I put this LOD chair? Oh, it goes in furniture/seating/lod? Thanks.

 

I think you're presenting this as far more complicated than it actually is.

Link to comment
Share on other sites

I have figured out a process how to recolor a texture based on the colors of another image.

 

Edit: Is someone interested in a tutorial on this? The idea is that instead of doing more screenshots in DR; re-aligning them in Gimp, etc. you just recolor the finished texture atlas. Advantage: It might be easier. Disadvantage: Sometimes results are unusable, needs quite a bit cleanup, and needs to be done on a high-res image or it will look pixelated. Of course, for LOD models it is perfectly fine.

 

Here is an attempt which isn't usable, but looks funky:

 

post-144-128542994598_thumb.png

 

Here is something more usable in-game, the yellow skin for the cattails4 LOD model (already comitted):

 

post-144-128543006892_thumb.jpg

"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

I'm trying to prove a point to keep the system simple. No reason to add another 30 folders for possbily 30 LOD models. It's just silly. Having the models all in one place with correct naming makes it easy to see what is what, whether models have LOD or not (which means they'll have an entity) which is easy to see without opening more folders.

 

As it is we already have alot of folders and none of them have more than probably 20 models in each. So having a few LOD models right next to them isn't going to clutter up the model viewer and make it 'hard on mappers'. But it is more work to do when placing models, when uploading models, when writing defs, when testing and troubleshooting.

 

And modellers WILL want to use entities, as most modellers make things for their maps that can be used.

 

And I'm not positive but I don't think the DDS folder was made as a way to organize (if it is it was a bad decision because it makes textureing anything twice as hard to even dfind what you're looking for), it was done because of how Doom deals with textures. Right?

So arguing that doing the same for models as was done for textures is silly because it's not the same thing and it's not for the same reason.

 

--------

 

981 * 2 = 1962 tris, which makes for a total of 17658 tris

 

I'm sure your math is wrong on that. First some of those tris are shadow mesh, the model editor just shows total tris per model. If it had collision mesh they'd be in there too. Probably 200 tris for shadow. So this model is optimized better than it may seem.

 

I could probably cut down draw calls by making the polies instead of having twosided, but that also has an issue, I have to nudge the polys apart 0.25 units so they don't z fight and that'll probably be noticeable on this model.

It hgas 3 materials because I recycled the lily stem and the leaf. It could probably be combined into one tex, but that'll bloat the tex size of 3 skins in favor of fewer draw calls...

 

But still, in editor with one lily and 3 lights I get 45 draws looking away (in a box) and 69 looking at it. And I get
10,000
tris looking at it and 4,000 looking away. So I'm not sure exactly how those tris are counted.

Probably 3 lights x the twosided polys for flower and leaf. But the stem is not twosided. The model is only about 700 tris and only casts shadows from 200 tris.

 

No shadows its 59 draws unless I stand right ontop of it where the draws jump to 80. So I don't know exactly how that works either.

 

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

And I'm not positive but I don't think the DDS folder was made as a way to organize

 

No, it is simply a D3 requirement.

 

--------

 

981 * 2 = 1962 tris, which makes for a total of 17658 tris

 

I'm sure your math is wrong on that. First some of those tris are shadow mesh, the model editor just shows total tris per model. If it had collision mesh they'd be in there too. Probably 200 tris for shadow. So this model is optimized better than it may seem.

 

Ah, ok, yes, I overlooked it. Would still 700 * 2 = 1400 tris for the model in 3 surfaces.

 

Please also note that I didn't mean to imply that this model needs less tris! If you can slim it down without sacrifying visual quality, cool! If not, no problem, the LOD system will take care of it
:)

 

Edit: Btw if you put two surfaces back-to-back to make a "two-onsided materials instead of one two-sided material", z-fighting is not an issue, because both surfaces will never be visible at the same time due to one being always backwards to the camera and thus getting culled. (Or at least thats my experience). End of edit.

 

If you have one little in a small room in a map, it will be ok. I am just working on my goal having a huge outdoor map, where you might have 50 different lilies on screen at a time, but most of them are only a few pixel. You can't leave them of (hide) the either, because it is due to their color, obvious they are missing
:)

 

But still, in editor with one lily and 3 lights I get 45 draws looking away (in a box) and 69 looking at it. And I get
10,000
tris looking at it and 4,000 looking away. So I'm not sure exactly how those tris are counted.

Probably 3 lights x the twosided polys for flower and leaf. But the stem is not twosided. The model is only about 700 tris and only casts shadows from 200 tris.

 

The problem is that in game, each triangle is shaded for each light, and you can easily have 3 or more lights without having any extra light entities in the map: ambient, a fog/blend light, a local ambient light, and the player lantern. Add to that a streetlamp or torch, and you can see why this can add up quickly.

 

But as I said, I didn't say you should change that model. I used it just as example.

 

No shadows its 59 draws unless I stand right ontop of it where the draws jump to 80. So I don't know exactly how that works either.

 

Yeah a lot of these things seem not to accurate. I just use them as rough guideline => less is better
:)

"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

As it is we already have alot of folders and none of them have more than probably 20 models in each

 

 

The tree folder (which will see a lot of LOD use, I imagine) already has 33 models in it. Even if only half of those models get LOD versions, and each of them gets only 3 extra LOD stages, you're raising the number of models in the folder to about 80. The difference between scrolling through 33 models and scrolling through 80 models is more than just a little significant, IMO.

 

Not to mention that we hope to continue to add models as time goes on. How many models will be in the folders three or four years from now?

Link to comment
Share on other sites

I don't want to butt in with the forks and knives and plates flying around :blink: but a quick skim of the thread, and a suggestion. If my suggestion is not valid, or already stated and dismissed, or whatever else, please just ignore it (and don't throw that cleaver!) and chalk it up to the "quick skim" part.

 

Sounds like one side wants:

models/type1 (e.g. furniture)/

models/type2/

etc.

 

Period, that's it. Like now. Everything, originals and LODs in same folder.

---

 

While the other side wants:

models/type1/lod

models/type2/lod

etc.

 

Each subcat having an extra lod folder. That doesn't sound like a big deal to me, but ok; I assume modeling program -> output file -> TDM can be a pain with that.

---

 

 

How about,

models/lod

models/type1

models/type2

 

?

 

That is, have ALL lods in one folder of their own, period. They can be browsed that way in DR, or ignored just as easily. And they're all in one special folder, instead of dozens of special folders. And the modeler's overhead is reduced.

 

Again if this is already suggested and dismissed, then nevermind.

Link to comment
Share on other sites

(snip)

Sounds like one side wants:

models/type1 (e.g. furniture)/

models/type2/

etc.

 

Period, that's it. Like now. Everything, originals and LODs in same folder.

---

 

While the other side wants:

models/type1/lod

models/type2/lod

etc.

 

Each subcat having an extra lod folder. That doesn't sound like a big deal to me, but ok; I assume modeling program -> output file -> TDM can be a pain with that.

---

 

 

How about,

models/lod

models/type1

models/type2

 

?

 

That is, have ALL lods in one folder of their own, period. They can be browsed that way in DR, or ignored just as easily. And they're all in one special folder, instead of dozens of special folders. And the modeler's overhead is reduced.

 

Again if this is already suggested and dismissed, then nevermind.

 

The problem with your scenario is that if you want to look at "model", "lod1, "lod2" in editor (to compare them), you need an expensive folder traversal just between "model" and "lod1". In my working with creating with models, that's proved already a serious hassle, as you constantly click around in the tree, instead of just selecting the model below the one you currently have.

 

So the "one LOD folder per category" puts them more closer.

 

In any event, all this is just sugar, as long as we actually have the models, and they are linked in the entities, mappers will be happy. Trust me :)

"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

Made a set of four maps that consists of a black room (you can use it => black background, select it => redbrown background, or hide it => grey background) with for manually edited camera positions and a example model at the center.

 

Get it here:

 

http://bloodgate.com/mirrors/tdm/pub/lod_construction.zip

 

This should make it easier to create screenshots. Just drag the viewport big enough, position the camera via cursor keys or the "strafe" keys, and shot away.

"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

I imagine that this is kind of a call to the community to make versions of these for the existing assets ???

 

If so, do you have a list of the assets that have gone through this process?

 

Maybe we could create a wiki and any mapper could write "Got it" next to entries that are listed as incomplete?

 

(or just put the table on the "discussion" tab for the existing tutorial wiki?)

 

(I will even try this if I can squeeze enough PC time from my restrictive wife...)

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I imagine that this is kind of a call to the community to make versions of these for the existing assets ???

 

If so, do you have a list of the assets that have gone through this process?

 

Well, yeah, help would be nice :)

 

I just created this list:

 

http://wiki.thedarkmod.com/index.php?title=List_of_LOD_Models

 

Although, using the new maps, and the idea of creating exactly one texture atlas for all cattail models (because this can save drawcalls if we ever combine these models, plus on 1024x512 texture fits 3 models, whereas before I needed 512x512 for one model), it took me 20 minutes to create the nec. screenshots (yellow+green skin), and arrange them into a (more tightly fit texture) in Gimp:

 

post-144-128585356861_thumb.png

 

Then it took me 7 more minutes to paste the yellow variant over it (if you copy&paste the new skin into a new layer with the same mask, you can align it pixel-perfectly very easily (use the zoom, luke), and then you just need to color-correct, scale and export as TGA:

 

post-144-128585358529_thumb.png

 

The final high-res atlas (for reference in Gimp format) is here:

 

http://bloodgate.com/mirrors/tdm/pub/textures/cattail_atlas.xcf

 

Now I just need to make three patch-based-models and apply the new texture, then check it into SVN. I'd say if you know what you are doing, 30 minutes for one texture atlas + model might be doable. Took me an hour with this post and the wiki entry for three models.

 

(I will even try this if I can squeeze enough PC time from my restrictive wife...)

 

You spent a lot of time posting/reading here, just cut down on the rambling and make some models. Your wife will understand that you do something useful here :)

"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

I do most of my forum posting at work. :laugh: It would be cool if I could fire-up Dark Radiant here too... (maybe during slow season on Sundays...)

 

(Don't get married?)

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

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

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • 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
×
×
  • Create New...