Model issues

[Springheel]

40 lowpoly ropes with shadow mesh = 60 FPS whether or not I looked at wall

 

40 high poly ropes (with untouched tex-has noselfshadow dec) = 25 FPS

40 high poly ropes (edited mtr, NoShadows, NoSelfShadow) = 45 FPS

 

I don't quite understand. It looks like you're saying you got 60 FPS when using a lowpoly shadowmesh, but 45 FPS when using no shadows at all, but clearly that can't be right.

[Crispy]

I don't quite understand. It looks like you're saying you got 60 FPS when using a lowpoly shadowmesh, but 45 FPS when using no shadows at all, but clearly that can't be right.

Reading carefully, it sounds to me like the 60FPS test case is using a lowpoly visual mesh, not just a lowpoly shadow mesh. So that does make sense, and suggests that the highpoly visual meshes are having a measurable effect.

[Baddcog]

Yeah, that's 60 fps with:

 

Low poly mesh that has a low poly shadowmesh. That model is 318 polys in DR, it seems as though the shadow is a copy of the original mesh.

So the mesh is probably 160 polys, and the shadow is 160 polys.

 

The frames per second stayed the same whether I looked at ropes or wall. (40 low poly ropes with shadows)

------------

the 45 fps is when I looked at the high poly ropes (40 of them) and they had NoShadows, noselfshadow

So yes, polys do have an effect but the numbers are substantially different.

 

We're talking a total of about 13,000 for the low poly ropes on screen. FPS didn't flinch at that.

 

But the high poly mesh is 2,500. So that's a total of 100,000. Quite a difference. That extra 90,000 rendered polys did have an effect on framerate, but very few objects are even close to 2500 polys.

------------

It's the 25 FPS because of the 90,000 polys casting Shadows that I'm looking at though. That's only shadows too, that wasn't self shadowed.

 

My point is that if those ropes had shadow meshes of 160 polys with shadow2 (noselfshadow) there might not even be a noticeable drop in FPS even with the high poly meshes (a FPS drop below what the meshes themselves create)

But if they don't have the low poly shadow we lose 20 FPS right there, that's even more than was lost on the high poly visible meshes.

[Springheel]

When I posted my test, I was *adding* a lowpoly shadowmesh to the existing highpoly model, not replacing it. Since that's what we're talking about doing in game, that seems to make the most sense for tests.

 

We're talking a total of about 13,000 for the low poly ropes on screen. FPS didn't flinch at that.

 

But the high poly mesh is 2,500. So that's a total of 100,000. Quite a difference.

 

Ok, so 100000 polys is harder on fps than 13000. That seems pretty straightforward.

 

My point is that if those ropes had shadow meshes of 160 polys with shadow2 (noselfshadow) there might not even be a noticeable drop in FPS even with the high poly meshes (a FPS drop below what the meshes themselves create)

But if they don't have the low poly shadow we lose 20 FPS right there, that's even more than was lost on the high poly visible meshes.

 

Here's where I get confused again. Your first statement seems to agree with my test--that have a lowpoly shadowmesh inside the highpoly model did not seem to have any impact on FPS.

 

But then your second statement seems to disagree, by saying that if we don't have the lowpoly shadowmesh, we lose more FPS?

[Baddcog]

What? Now I'm confused.

 

Simple

high poly mesh with NO shadowmesh casting it's own shadows does impact framerate in a big way.

 

If we put a low poly shadowmesh inside a high poly mesh it should help with that.

[PinkDot]

That model is 318 polys in DR, it seems as though the shadow is a copy of the original mesh.

Actually it's nearly exact copy except for the faces with transparency - they shouldn' cast a solid shadow so no shadow is better for them.

[Springheel]

Simple

high poly mesh with NO shadowmesh casting it's own shadows does impact framerate in a big way.

 

Ok.... I didn't think that was ever in doubt.

 

My question was whether adding a lowpoly shadowmesh to a highpoly model actually HELPS reduce framerate in any significant way. While intuition would say yes, my tests on the rope suggested that it had no tangible effect at all.

 

I thought you posted your rope test results to show that it *did* have an effect, but now I'm not sure.

 

Your tests on the gargoyles suggests it might have a minor impact if many lights are hitting the objects, so I still have to test that to confirm. However, it seems safe to say that unless the shadowmesh is *considerably* fewer polys than the main model, then it probably isn't worth adding one.

[Baddcog]

Agreed. and that's what I've been working towards. I have added 500 polys shadow meshes to a few objects, but these are the objects in the 2500 poly range, so I think that's considerable.

 

Most other shadow meshes have been around the 100 range. I have been trying to skip objects of 250-300 polys and work on the bigger stuff first.

 

Therefore I think probably a good reduction to aim for is having the shadow mesh be about 20% of the original polys. (with exceptions like the low poly rops/transparency issues) I think to get a good shadow mesh inside and object so it can cast self shadows, 20% is probably about as low as we can go, then you really start fighting with not having the mesh stick out.

 

Collision models are ending up much lower, maybe 5% of the original polys, and I think that'll be critical when it comes to path finding. That's still untested on my end but it makes sense.

[Springheel]

Well, even if we can get the shadow mesh looking good at 20% (which I'm not sure we can), I don't know if it's worth it for objects that are less than 300-400 polys. If you take a 200 poly object and make a 40 poly shadowmesh, you're only saving about 100 polys total. That isn't likely to have any significance unless you have hundreds of them on screen at once. For objects like that, it might just be better to leave it be.

[Komag]

I'd love to try out my 1600 Barrels drop with 1/5 shadow mesh barrels! Probably go a lot smoother

[Sotha]

WARNING: ConvertLWOToModelSurfaces: model models/darkmod/nature/trees/tree_dm.lwo has too many verts for a poly! Make sure you triplet it down

[Springheel]

I think the spec map is the problem, you have 2 diffuse maps listed.

 

Hmm, now the knocker looks like this on my system:

 

 

Now it has no shadows AND the wrong texture.

 

edit: Christ, it looks like all the doorknocker textures are messed up. I love taking my one hour a day to work on the mod to fix things that were already working before.

 

(not directed at you in particular bd, just a general frustration)

[Baddcog]

I can revert what I did. All I did was chagne diffusemap to specularmap. (the second diffuse map listed there, I didn't change tex names or anything) it's possible you wanted the first diffuse for spec and the second for diffuse?

 

I know how you feel though, I've redone alot of stuff that I was never aware got broken to begin with, just stumbled apon it.

 

It just looks to me like your shadow mesh sticks out of the mesh and is casting a shadow on itself. If you use shadow2 instead of shadow it will get rid of that issue.

[Springheel]

It's ok, I fixed the problem. No worries.

[Baddcog]

candlestick2.lwo - improper collision mesh for moveables, can't pickup, doom3 gives error, can't go ingame

candleholder.lwo - same

[SneaksieDave]

Yeah something's been wrong with these for a while: http://forums.thedarkmod.com/index.php?showt...78&hl=torch

[Baddcog]

@Springheel - or anyone who wants to help with LWO files

 

Wrapping up existing objects and getting them all moveable. I've got a couple ase's to fix, these lwo's need a collision mesh that'll work for moveable. Most of them have no collision now, if they do Doom wont load them

 

//Need to add from models:

//all signs, need collision models

//decor/wall/horshoe needs collision (I know this is for hangin, but probably a good junk model too)

//tools: pick axe, pitch fork, smithy hammer, spade, drawing compass (also missing shader)

//wearables: belt pouch, boot large, cap rish ,inventor goggles, spectacles

//kitchen -food- cake, muffin.

//junk- chair 3 leg collision too complicated for moveable.

//hat broadbrim model too complex

//tools/household/ broomstick, brush and mop need collision. mop needs texture work on handle, missing mop tex

//readables/ book red, book small red, book tome, [gui_paper, gui_scroll_01 - can/should gui items be picked up?], paper1, scroll1,

 

 

//statuette priest.lwo needs collision (could be taken from guard statuette). I suppose we want these moveable, if not frobbable at least able to tip over. There seems to be a problem with shadow meshes and moveables, I can still see the shadow tex in game ?

 

---------

once i see them finished I will add to moveable.defs (I am splitting moveable def's into a few files, it's getting hard to find anything.)

[Springheel]

//statuette priest.lwo needs collision (could be taken from guard statuette). I suppose we want these moveable, if not frobbable at least able to tip over. There seems to be a problem with shadow meshes and moveables, I can still see the shadow tex in game ?

 

I don't think we want those busts to be moveables...I'm pretty sure the bottoms have holes in them. In RL they'd probably be heavy enough to justify leaving them static.

 

There's a problem with those statues--they currently use generic stone textures that we can't set to noshadows. We'll need to make new, specific statue shaders, and then redo all the skins. I haven't felt like tackling that yet.

[Baddcog]

Alright, I'll cross those off the moveables list.

[Baddcog]

candle_holder.lwo's collision mesh extends up into candle area, candles now have collision so it could be touched up.

 

-------------

New candles open a can of worms.

 

There are currently 2 entities for them. One with candle flame (non-moving) attached and one without flame.

 

IMO the best option would be to remove candles from all existing lwo candle holders and only release seperate candles/holders.

 

I can't edit the lwo's so this would be a chore for someone else unfortunately.

 

The reason for this would be to allow authors great choice on candles/heights/new/used... and the number of candles per holder (some hold 3-6 candles)

It would also allow candles to be frobbed seperately to turn them off/on. Or if water only hit 2 of 5 only 2 would go out...

 

One of those things that must've improved after the original models were made.

 

This also allows for the skins to be swapped with the glowing candle skins.

[Springheel]

candle_holder.lwo's collision mesh extends up into candle area, candles now have collision so it could be touched up.

 

Ok, I tracked down why it's like that:

 

Make the collision mesh of the candle holder extend all the way up to where the candle would be, then make it the bindmaster. One or the other collision mesh will be ignored when they're bound together, so if we make the bindmaster collision mesh extend out over the bound object too, that should work. This is unfortunate and not elegant, but seems necessary unless a major overhaul of the binding physics code can be done.

 

I don't know if the physics issues have been fixed since then, but perhaps it's better not to mess with what works right now.

[Baddcog]

Alright, even if one has no candle and got dropped on that side it would probably roll over a bit anyway. I can live with it.

[greebo]

There are a lot warnings written to the console when loading the current church.map, which are caused by the files models/darkmod/nature/trees/gw_dm1_tree_02.ase and models/darkmod/nature/trees/gw_dm1_tree_03.ase. Doom 3 complains about the HELPEROBJECT tags:

Unknown token '*HELPEROBJECT'
Unknown token '{'
Unknown token '*NODE_NAME'
Unknown token '"Axis"'
Unknown token '*HELPER_CLASS'
Unknown token '"Dummy"'
Unknown token '*NODE_TM'
Unknown token '{'
Unknown token '*NODE_NAME'
Unknown token '"Axis"'
Unknown token '*INHERIT_POS'
Unknown token '0'
Unknown token '0'
Unknown token '0'
Unknown token '*INHERIT_ROT'
Unknown token '0'
Unknown token '0'
Unknown token '0'
Unknown token '*INHERIT_SCL'
Unknown token '0'
Unknown token '0'
Unknown token '0'
Unknown token '*TM_ROW0'
Unknown token '-0.3890'
Unknown token '-0.1207'
Unknown token '-0.3589'
Unknown token '*TM_ROW1'
Unknown token '-0.5049'
Unknown token '0.3859'
Unknown token '0.4176'
Unknown token '*TM_ROW2'
Unknown token '0.2467'
Unknown token '0.9627'
Unknown token '-0.5913'
Unknown token '*TM_ROW3'
Unknown token '0.0000'
Unknown token '0.0000'
Unknown token '0.0000'
Unknown token '*TM_POS'
Unknown token '0.0000'
Unknown token '0.0000'
Unknown token '0.0000'
Unknown token '*TM_ROTAXIS'
Unknown token '0.2779'
Unknown token '-0.8574'
Unknown token '-0.4331'
Unknown token '*TM_ROTANGLE'
Unknown token '2.6065'
Unknown token '*TM_SCALE'
Unknown token '0.5429'
Unknown token '0.7604'
Unknown token '1.1564'
Unknown token '*TM_SCALEAXIS'
Unknown token '0.0000'
Unknown token '0.0000'
Unknown token '0.0000'
Unknown token '*TM_SCALEAXISANG'
Unknown token '0.0000'
Unknown token '}'
Unknown token '*BOUNDINGBOX_MIN'
Unknown token '-3.4220'
Unknown token '-4.4079'
Unknown token '-4.1032'
Unknown token '*BOUNDINGBOX_MAX'
Unknown token '3.4220'
Unknown token '4.4079'
Unknown token '4.1032'
Unknown token '}'
loaded collision model models/darkmod/nature/trees/gw_dm1_tree_03.ase

 

I assume these are remnants from a 3DS export? Baddcog, can you try to open and re-export these two ASE files? Maybe the HELPEROBJECT stuff goes away then.

[Baddcog]

I'll take a look at them in notepad and see if I can fix em. Unfortunately I can't get Max 5 to run in Vista-so NO ASE import.

 

And nobody has made an ase importer for Max 7 which I can run in Vista...

[greebo]

@Springheel: The citywatch mesh is a bit, erm, changed since last night:

 

 

What changes have been made here?