Baddcog
-
Posts
5348 -
Joined
-
Last visited
-
Days Won
13
Posts posted by Baddcog
-
-
posted image not loading
-
^ anyone else have opinions on that before i get too far
=========
I see where you're coming from, it's a legitimate point.
I personally like the pronounced bevel on the edges. Might not be 'historically correct' but it looks good in game.
I can make it really small but almost seems like a waste of tris then. (and if I do it in a normal map for the high poly it also interferes with easy of skinning - instead of using stones normal it needs a specific one for high and low, and different rock textures, etc..)
If I make a texture specifically to show the cracks (and no geometry) then that limits the use of skins from base materials. The uv's are rotated on each section, so if the texture has any noticeable grain it will be offset and show the splits better. but for such a plain texture as this it really doesn't show.
-
alright, it's up in the svn folder
darkmod/models/mapobjects/cagelight/cagelight.ase
Shows up right next to the doom3 .lwo version. I guess when the lwo is removed it will override, not sure how to check.
-----
I guess now it also needs an entity and skins. We have a green metal that matches and a dark glass for unlit so...
-
made the cage light in DR.
Should I put it in darkmod/models/map objects?
or models/mapobjects?
-
anyone else tired of pillars? I am.
Started over on the pillars to try and get the dialed in good. Decided to go with sharp edges for the normals, makes it much easier to swap and get a consistant look then the soft edges. Also looks better i think.
Only have the huge pillar redone, think I'll stick to 3 sizes not 4.
This pic shows (right to left) High pillar (normal map is stone textures normals) up close, 350 units, then 750 units. Swap at 750 to the mid detail (normal map version - lower shadow and coll, 16 sided), then at 1250 the lowest res swaps in (8 sided)
High is 2040 tris 9shadow coll included)
mid is 568 tris plus normal map
low is 282 tris and normal.
-------
Setting the lod detail to highest forces the high detail to never change. But lowest SHOULD make at least the mid show and never the high, but they are swapping at the distances set still. hmm
-
Well, that pic is completely random, are those correct room sizes? light volumes, etc...?
We have a lot of indoor type maps and they all seem to perform pretty well, and i don't think any of the authors compromised on lighting too much.
It's just something you have to work with a bit to get best perf. Maybe slide a torch down the wall a couple units, cut up a brush somehow so it's tris are smaller... But that stuff only if you are starting to see a big drop in perf.
-
You could probably script lights to turn off at a distance, or by triggers so if you know the player will never see the actual light from a source it will turn off.
probably more trouble than it's worth. And probably only worth doing a few lights if they really need it. Could get pretty complicated having tons of triggers around.
Also that pic above is 'wrong'. Lights appear to have a radius because of the shader textures on them. But all lights are square so they'd actually overlap more than that.
-------
Even if you leave a portal area the lights are still on, while they may not be cast on tris that are no longer rendered they can still be hitting tris through a wall and effecting performance. Best just to try and minimize that, smart light placement.
And also NOT optimizing terrain too much, so you have smaller tris that won't be hit by as many lights (balance between making them small but not making too many small ones).
-
looks great!
-
It probably has less to do with 'not being part of TDM Universe' and more with 'possible copywrite infringement issues'
Baffords/Duffords...
That's not my call, it's my guess
----
There's warnings on the wiki about that... if it's possible infringment on an ip it's possible the mod could take heat, thus the mod can't 'officially support' it. Thus not in the DL list or wiki.
-
Well they should effect performance by making it better
-
Well, the impact comes into play more with the menu settings imo.
the model has to switch at a fairly good distance to not notice the 'pop' anyway. So most likely the LOD useage is more because someone has a slow system and chooses 'low' in the menu, or they have a really good system and they choose 'highest' which would never switch to a lower model.
----
But that said, in my test between my machines lod would be thus:
High End PC : i would always be 'in room #3' and still be getting 45-60 FPS and best details.
On my laptop i would be in room #2 and be seeing the medium detail models and getting 30-45 fps.
not based on distance, just on user settings.
-----
Of course it's an extreme example, especially with the low amount of lod models we have. And considering much of the detail will be terrain brushes and func_statics that probably won't be LOD anyway.
i'm not expecting that we'll see any huge gains in performance or anything. just trying to clean up/future proof the system. Which right now is more about establishing a system to use in the future.
======
I guess tels isn't dropping by much more anymore these days but from looking into this my opinion is swaying more towards using really high distances for the LOD swap than we previously looked at.
Which would basically just force the LOD to almost never change models, so the only model changes would be menu settings. Authors can always quickly over rie on an entity basis if they need to get more perf.
this would also fix the hassle i am dealing with now, which is getting the low poly/normals map model to look very similar to the highest poly model. They just don't render close enough to make the swap easy and clean.
-
(i was writing this at the same time nbohr1more was writing his post so...)
true the highest hit to performance is shadowcasting tris/multiple lights per tri.
but again, the more detail you put in the more impact it has. So where ever we can save is good.
This isn't only about Skyrim vistas though. it's about performance scaling for all users to give them the best visuals on their machine. it really is more about the system detail settings than distance imo. Of course they are tied into the same system.
-------------
Not really scientific but I did a test here...
I made a map with 1 very large room, approx 4,000 units by 6,000 units. (this is a VERY large open area). It was just a cube so I sliced the brushes up into a bunch of smaller brushes and put alternating textures so they won't optimize back down into 6 giant brushes (keep terrain light count out of the study).
I randomly placed a bunch of lights and a world ambient just for 'random light count'.
i cloned this room for a total of 3.
One i left empty. one i placed 96 of my 'low poly' pillars. and the third had 96 high poly pillars (same exact placement as #2).
On my laptop (ati 420 mobility card (pretty weak) and win 7.
Room 1 i was getting 60+ fps. Size of area doesn't seem to really have any effect.
Room 2 i was getting approx 45 fps. (96 lowpoly pillars with low poly shadow mesh). Pillars have a total (with shadow) of 568 tris each.
Room 3 I was getting 15 FPS. ( 96 hi poly pillars, 2040 tris each including the low poly shadow mesh).
--------
So there's definitely an impact. in this case it could be more about the high amount of tris receiving shadows, not about the low amount of shadows being cast.
So it does show that no matter what, tris casting OR receiving lights have an impact.
I'm pretty sure on my desktop room #2 would still be at 60 and the 3rd would be around 30-40.
========
Further testing:
I replaced the shadow mesh with caulk on the pillars in room #3. So NO shadow casting, ONLY light receiving. An no more than 3 lights on any tris.
Still sitting at 15 FPS. IF I look away so only half the pillars are in view i get 25 FPS, only half again an I get 45 FPS.
So yes, just lighting a bunch of tris does have a pretty good impact on a lower end system.
=======
But we are talking about a LOT of tris. 96x 2040 = 196,000. Definitely more in view than T2's limit of 1024.
=======
moar test:
On the other end of the spectrum. i made two new rooms.
1: 3 low poly pillars
2: 3 high poly pillars (same shadow mesh)
3 lights in each.
in this case my FPS is sitting at 60 in each room. So there is definitely a cutoff somewhere where performance starts to 'tank'.
-------
So...
The 2000 - 6000 tri range with reasonable lighting is basically no performance hit.
once I hit 50,000 tris (casting/receiving shadows - reasonable lighting - around 3 lights per tri max) I started taking a pretty decent hit of 15 FPS. Still very playable at 45 IMO.
100,000 tris (casting/receiving shadows - reasonable lighting - around 3 lights per tri max) I was hitting what I think is about as low as you want to go, 30 FPS. i think at 30 FPS you can still have reasonably good gameplay. but this is ONLY rendering. No ai thinking involved, so 100,000 tris per scene might be pushing it for good performance/gameplay.
At 200,000 tris (casting/receiving shadows - reasonable lighting - around 3 lights per tri max) my laptop is pretty much tanking at 15 FPS.
------------
What does it all mean regarding LOD models?
Well, that depends on several factors, but we new that.
View distance, map detail, visportalling, system map is run on, if the author uses reasonable lighting or not...
obviously we can push pretty good detail, but it does scale to the system. LOD is a way to push as much as possible on the users system.
(i didn't test THIS map on both of my systems, but i get 25 FPS on this system in my city map in spots i get 60 FPS on my PC, so using that as a general guide to what i would expect).
------
But keep in mind, I am not pushing to start making LOD of every model in game. obviously to have an lod of a goblet that is less than 150 tris isn't going to do much for us at all. you'd have to have 20,000 of them in a room to make it worth while.
Mostly i'm concerned about future scalability/ease of use/folder structure. The 'popping' is more of a setting value. We can set the distances pretty high to minimize the noticablilty, but that still leaves LOD as a system setting for low enders.
Most of the newer models I have made I made higher versions of because of the LOD system. For the most part if you are baking a normal you are already well on your way to easily making a few detail meshes.
Either way:
IF we just put an LOD folder in the models forlders so they can be seen it really doesn't clutter the editor, but it helps people find/be aware of them. (or just decide if they want more or less detail default in their map) (ie: i want big pillars but this scene is already so complex, i'll go for low poly version- or i really want this place to look good, I go for high)
So I guess the best thing we can do IMO is to set up a folder structure like this and let mappers decide. then the player also has detail settings to choose IF authors wish to use lod entities.
Whether or not new models are made with lod, or old ones are retrofitted will really be up to each modeler to decide for themselves.
-
1
-
-
You can definitely see the indentations up close on the high poly models. The round ones look a bit flat. it's really not a huge thing. But now with an i5 processor and TDM running so smoothly I would like to see the best details possible. But I don't want lower end users to suffer either, that doesn't help TDM. And since we have a system that works best for both users I think we need to use it.
-
I skipped the posts here to being able to make a neutral post:
I know there are two things I heard of but never saw them / got used to them. One of them is placing objects randomly within an area and the other is placing an object in different shapes. So from reading the topic LOD means level of detail and this is the one that places a high poly model if you are near it and a low poly one if you're far, right?
Voted "wut is that" because I never saw this and never used this sadly.
Well, random placement is SEED, which is tied into LOD.
Yes LOD is basically high level up close and low further away. But also changes due to menu detail settings (lower for lower end users)
I know they exist.
I don't know how to use them.
I don't know where to find them.
That's what I am afraid of. (my posts above explain), but we need it to be second nature for mappers IMO.
=======
And hopefully my posts are neutral enough. just trying to find the best option for TDM/mappers, personal bias aside.
-
Sorry for spamming posts but I think these things need to be easier to find
============
So a question for mappers on finding them:
Is the current local bad.:
models/misc/lod/architecture/pillars (standard model directory under lod). IMO this hides them out of sight/out of mind.
whereas
models/architecture/pillars
models/architecture/pillars/lod
would show you when browsing for models that the pillar you are using MIGHT have an lod entity/models. At which point you can look and see (if there are no LOD models there won't be an lod folder in said directory). If it does you can create an entity instead.
Or, if you just refuse to use LOD (don't see why but for sake of argument) then you can choose to either force the highest or lowest detail version on the map. (and in some rare instances you might prefer a lower poly version [ say a 6 sided fountain as opposed to a very round one).
==============
I'm bringing this up now because we do have very few models. If we choose to fix the directory now we can leave the existing ones in place (to not break maps) and we can place copies in the better location. it will leave a tiny bit of bloat but not much, if we do it NOW.
it will also make LOD more obvious NOW, which will start to improve performance now not later or ever and help people use and understand the system we have available to them.
-
I would use them for big outdoor area's if we have more of them. Eg tree's and bushes, we dont have nearly enough variety IMHO.
Yes but now you're talking variety. That's more models + lod's.
I was thinking about adding more branches to my pine tree models so they would be fuller and look better up close/on high settings.
But this harkens back to the original problem:
1: I either rename so the higher poly models would replace the existing ones (making existing maps look better, but taking a possible slight hit in perf ... they will have the same shadow meshes) and use the existing ones as low detail replacements (would only be seen in new maps that use an entity).
2: I do the work, stick them in a folder where they will never be seen. They MIGHT be used in future maps as entities.
-------------
It's not so much about adding more variety at this stage, as much as it is about making TDM more beautiful and optimized.
Of course any future models are more likely to come with lod's right off the bat anyway.
-
In my opinion the main issue is that they are no longer models, but entities.
So when decorating a scene who thinks of using an entiy? If it's a light, sure. But if it's a pillar... just a static object that doesn't appear to 'do' anything.
And seeing as how few of them there are it seems they'll only be used because someone knows that particular model is optimized.
-
added...
True, they are great for high detail scenes. Large spaces, etc...
BUT, that is NOT the main point of them anyway.
The main point is that you can use the entity instead of a model. And when a user has their settings on HIGH, then they see the highest poly models up close no matter what. If they have the details set on medium then they see highest up close ( but the details will drop at distance). If they have settings on low they will never see the highest poly models for performance on lower end systems.
If you just use models you either use a medium detail and nobody ever sees how pretty TDM could be. Or you use the highest and low end users suffer in your map.
Tels did a great job of scaling detail based on system settings AND distance.
----------
But realistically it would be best if all models had them for performance. Not saying that anyone is ready for that task, it can be hard to recreate models in higher versions, takes time...
But if they don't get used what's the point in having them.
The pillars I'm making for example, takes a lot of extra time to do all the extra models and stages. Then if they just end up sitting in a folder somewhere and never used...
We can always keep upgrading and putting the highest details in the models folder, so TDM always looks best. But that's not best performance wise. (but TDM is performing pretty well these days)
---------
Authors can make their own LOD's, shadowmeshes for terrain , etc... for better performance. But that only goes so far in the editor. And that's for stuff they create. Imagine trying to make a lower poly version of a standard object in TDM just for your own map. That's a lot of work to add LOD for one object (and honestly in most cases just wouldn't look good with editor tools. To get good uv mapping you're almost required to use patches and you can get much better more optimized shapes in a modelling program).
----------
I see no reason why TDM can't handle large areas like in dishonored. The city map I am making has some pretty large long views. However I haven't added tons of details yet and have optimized them pretty darn well anyway. (remember too though that Dishonoured has load zones... In the street of the second map when you can go into the doctor or the place across the street, each location is in a new zone. in TDM you would open a portal and go through a door, possibly leaving it open and having an even larger space to render)
Doom3 handles polys pretty well (and open spaces for that matter), that's really not a question. It does come down great to number of overlapping lights and searching ai that bogs down performance.
Even with LOD's we have stages:
1:Hi poly : lots of tris but lower poly shadow mesh (maybe even the low model or the low models shadow)
2: medium poly : still, shadow mesh is lower than model.
3: low poly : very low shadow mesh
4: lowest : shadow can be turned off completely...
5: turn off model completely.
Not all the models conform to that necessarily but those are the types of stages that can be set. Even just have LOD's for regular models that turn off shadows at a long distance can help perf. (of course the mapper can override this if the shadow is obvious).
-
Some people can't be convinced that TDM is a good thing. The more you try the harder they fight it, why bother. I wish more people would jump on TDM but we've got a pretty good list of FM's already.
-
Basically I'm curious who is aware of LOD models in TDM. If you guys realize we have them. If so, do you use them? Do you know where they are? Can we find a better way to manage them so authors can use them easily?
-
Well yeah, all the models on the left and on the ground are normal map bumps only (One is even same tex on a patch). maybe a little flat up close but still really not that bad.
But we have an LOD system and the high polys (with a normal) up close look pretty damn good (still using the low polys shadow mesh). But I had to tone down the normals for that one so the LOD 'pop' wasn't as noticeable. I think it always will be to a degree but that's LOD for ya.
Authors can still choose a static model so that doesn't happen.
Hate to include too many normal maps because of bloat, with normals still uncompressed they have a huge file size.
-
OK, so messing with the high poly a bit and not really getting what I want.
far right is the high poly model with the stone normals (no rib normals). Shading on a plain model is pretty bad. if i beveled all the edges more it might look pretty decent but would double and already hi poly count.
Second from right is LOD version. using the high WITH normals.
third is the high WITH normals. Having the geometry and the normals baked from it makes pretty strong shadows, and they have a noticeable pop even at a long distance with the LOD.
------
I guess an option is having a toned down normal for the highest poly. At half strength i imagine it would match the low with normals fairly well.
hmm...test...
But that complicates blending stone normals with these normals for stone even more complex and bloated.
-
3
-
-
Spring, could you rename or add to the name of the thread (Level of Detail)? I tried searching lod but search function...
---------------------
Anyway, it's almost impossible to trace down any conversations on this subject. Recent mapping/modelling has made me (re) aware of issues with LOD in TDM.
1: I seem to have put the medium LOD stage of my wrought iron hanger in models. Then the high and low versions in the LOD folder for the entity. Recently I had placed it in my map as a model and was wondering why i wasn't seeing the change in game. DERP. Also wondering why it seemed lower poly than it should be.
i know I took quite a break there but i made them and even forgot you had to place an entity. Now that can be fixed just by renaming the models and fixing the names in the def (basically making any used hangers hi poly and adjustments in the def shouldn't break maps).
SO...
How can we make it easier on mappers to choose LOD models (we obviously want to push this feature).
Are any mappers using the few we have?
2: OK, well I guess it's just one issue. but still... make LOD's, they are stashed away in entity/static/blah blah.. And with only a few models is it worth it for people to look?
LOD's are so much work and if mappers aren't aware what's the point? (i know future perf. etc... but realistically)
We can tag entities as having LOD stages (but the mapper already knows if they can find them), but the mappers are looking at models. how can we tag THEM to say 'has LOD entity'?
------
it's somewhat like people saying 'I didn't know TDM had difficulty settings'. but at least that is in a main menu up front. if they don't see that they aren't paying attention.
But LOD's are just hidden. It's like TDM's dirty little secret.
-
I was planning on making one piece that was broken off somewhat and probably one broke into 3 shards. I figure that would be enough for authors to mix it up. (remember each piece has to have 4 sizes - and that's not if I do higher and lower poly LOD's- then we're talking 8-12 models each piece). Of course the high poly models can just use the base textures normals because the model I used to bake the shape will be in game. So these are basically the medium res (I suppose most people will see) or at a distance for high end players.
And any texture can be used as a skin. The issue with normals is that the normals are baked for the carving. If the normals also have cracks and whatnot from each texture then they need overlayed/combined and that is more normal textures to be combined... That might be more of a possibility for one or two skins that look best, but a lot of bloat for 10-20 possible skins.
The spec is just from the base diffuse too so that can help break up the surface depending.
----------
But the repetitiveness also depends on texture. This first skin is just the grey sandstone. Not a lot of texture/color variation to it. But each 'segment' of the pillar is rotated on the texture, so a texture with more depth to it will break up each segment more, and there won't be obvious tiling top to bottom. That will also look better rotated because each pillar will then appear to have been made from different rocks.
The middle section can also be skinned a different rock/.texture from the end caps.
Darkmod: Inspiration thread
in TDM Editors Guild
Posted
Pretty good recreation. While really tall stuff looks cool I just find the proportions of the scene to be slightly ridiculous. Would like to see it in a much more realistic scale.