Bikerdude: - questions

[Baddcog]

Yeah, it's boosted to 8000... something

[Bikerdude]

well there is defiantly a light entity and light type limit when using a large leaf, such as the outside area in my contest map.

 

r_showLightCount ?

well spotted, now just gotta figure out how to use this info to position the lights etc..

Edited August 5, 2010 by Bikerdude

[Baddcog]

Have you any visportals in the outside area? Maybe even if they are huge, that should split it into more leafs.

[Fidcal]

After removing all the lights Im getting 63fps almost every where bar certain locations and high up.. With all the lights I get FPS drops as low as 23...

That's normal. Lights reduce peformance in any FM.

[Bikerdude]

Have you any visportals in the outside area? Maybe even if they are huge, that should split it into more leafs.

yeah, but it dosent help much, a few fps here and there.

 

That's normal. Lights reduce peformance in any FM.

Well, its partially the amount of light and something else to do with lights as I have reduced the amount from 40 down to 12 and Im still seeing fps drop to 35-45 in the same problem locations. Also when using the r_showlightcount cvar its saying that some surfaces have more than 3 light sources on them, when in fact there are no light sources at all...(Ive checked for internal lights overlapping to outside, and those have no-show turned off)...

[rich_is_bored]

Are you taking care to occasionally split brushes up so they don't span long distances?

 

For instance, say you have a long corridor with 6 lights up against the ceiling. Now say this ceiling is flat so you decided to use one long brush. In this scenario, the entire length of the brush will be rendered 6 times.

 

To improve performance, the ceiling needs to get broken up. But it's not enough to just cut the brush into 6 pieces. Because the same texture is used, it's aligned, and at the same scale, when you compile the map, it will merge those pieces back together.

 

To prevent that, you need to space the brushes apart, offset the texture alignment, change the scale, flip the texture horizontally/vertically, or use a different texture.

[Bikerdude]

ah ok, yes the brush/s in question are 2000 units long - so Ill split them up etc.

[Melan]

For instance, say you have a long corridor with 6 lights up against the ceiling. Now say this ceiling is flat so you decided to use one long brush. In this scenario, the entire length of the brush will be rendered 6 times.

 

To improve performance, the ceiling needs to get broken up. But it's not enough to just cut the brush into 6 pieces. Because the same texture is used, it's aligned, and at the same scale, when you compile the map, it will merge those pieces back together.

 

I learn something every day. Thank you!

[Baddcog]

You can also cut a brush in half, grab 2 verts that touch and just drag them done/up/sideways one grid square. That'll put them out of flush so they can't compile together. Shouldn't be noticeable either, and can add character

 

I was mainly saying add some visportals to cut up leafs so you can have more lights because they are spread out between more leafs then. Not nessecarily for more FPS.

 

And the world_ambient counts as one light, so everybrush has at least 1 to start.

[Bikerdude]

I was mainly saying add some visportals to cut up leafs so you can have more lights because they are spread out between more leafs then. Not nessecarily for more FPS.And the world_ambient counts as one light, so everybrush has at least 1 to start.

 

Main problem though BC, is I have a very hard to VP outside area, I have put in a few VPS but they only hellp a little.. I might get Baal toi have a look for me as he did a good job on one other maps.

 

On the amounts of lights, yes 85% of the outside surfaces are red (meaning 1 light) but others that should be red are showing up purple (which is 4+) which makes no sense - so as per your suggestion I am spliting the very long brushes into segments etc..

 

if that fails Ill try the vert grabbing option..

Edited August 5, 2010 by Bikerdude

[aidakeeley]

To improve performance, the ceiling needs to get broken up. But it's not enough to just cut the brush into 6 pieces. Because the same texture is used, it's aligned, and at the same scale, when you compile the map, it will merge those pieces back together.

 

That's a fault in the engine then? Why would the engine go out of it's way countermand something that improves performance? I mean this doesn't happen by chance - this stitching together - it is specifically programmed in.

 

Man, this stuff is so often so strange, because on the one hand there are things like this (split brushes up) and on the other things like that (combine-'em-all and convert to func_statics)...

[nbohr1more]

Probably related to rounding issues in the CSG math. Perhaps when the engine is Open-Sourced the CSG precision can be given more bits to work with?

 

http://www.modwiki.net/wiki/CSG

Edited August 5, 2010 by nbohr1more

[Baddcog]

Well, making them func_statics has a purpose.

To cut down on tri splits on anything made of brushes that doesn't seal the void so it simplifies rendering AND pathfinding. Ironcially then you need to add monster clip to improve pathfinding. lol.

 

 

combining func_statics into groups reduces batches and entities and thus improves performance.

 

----

When the engine purposely combines brush faces (like all engines) it is done to simplify terrain, cut down on tris and improve performance.

 

With this engine there is a cost with too many lights per face, but the engine is made to optimize terrain, not lights. There IS a command to split faces up based on light edges. It can help, but can also make tons of extra tris. So it's a balance also.

[Bikerdude]

what i dont get is the r_showlightcount command is telling me that some faces have light on them where its impossible. I imagin its down to a lack of understanding the tech on my part though..

[Baddcog]

A screenshot would really help

 

Is it on a really large tri?

 

And be aware, it doesn't have to be a tri that's 'lit'. A torches light source is only half in the room it's in, half of it is hitting tris on the other side of the wall, even though it's casting a shadow on them (from the wall).

[Bikerdude]

And be aware, it doesn't have to be a tri that's 'lit'. A torches light source is only half in the room it's in, half of it is hitting tris on the other side of the wall, even though it's casting a shadow on them (from the wall).

Hmm I did wonder about that - I had foolishly though that if "noshadows" was off, the light would only hit one side of the brush. In fact BC, would you mind having a look at my map and see if there is anything that can be done..?

[Baddcog]

Sure, email is my user name @gmail

 

I'll be home tommorrow night and can look then.

[aidakeeley]

Baddcog, all I can say is that I'm glad you guys understand the intricacies of the "light edges" vs. "terrain" well enough to be able to strike the balance if needed.

[Bikerdude]

making a skybox....

 

- http://www.doom3world.org/phpbb2/viewtopic.php?t=3571

 

but how would i do the same thing for TDM..?

 

I have already found a set of images and converted them to TGA

[rich_is_bored]

It should be the same process. I wrote an article about it on modwiki.

 

You already have the images. All you should need to do is make sure each image is named and oriented correctly.

 

 

So say you wanted to make a cubemap called "bikersky" you'd need...

 

bikersky_up.tga

bikersky_left.tga

bikersky_forward.tga

bikersky_right.tga

bikersky_back.tga

bikersky_down.tga

 

Then you place those images in the \env folder.

 

Then you write a material shader that references "bikersky" like this...

 

/textures/skies/mycustomsky
{
{
	blend add
	cameraCubeMap env/bikersky
	texgen skybox
}
}

 

... save it to a .mtr and place it in the \materials folder.

[Bikerdude]

sweet so a simpler version than the one I found on the doom site, thanks RiB.

[Bikerdude]

Another question:

 

how do i change to colour of my "light/moon" beams..?

[Serpentine]

Select the beam(s) they should be func_statics already so just go to the entity and make a new spawnarg "_color" and set its favlue to some random letters then hit enter to add it to the entity(s). Select the arg now and it should give you the colour picker button. Select the colour, the darker the colour the more transparent it will be. If you find a nice colour but just want to make it less visible decrease the "value" value in the colour picker to make it darker.

 

I think for some of them you need to play with shader params, but from what I remember I just changed the colour like that and it worked fine. I could be completely incorrect

[Bikerdude]

I think for some of them you need to play with shader params, but from what I remember I just changed the colour like that and it worked fine. I could be completely incorrect

yeah thats not working for me, I checked the yellow beams in the training mission and they dont use that arg for their colour...

 

 

Edited August 10, 2010 by Bikerdude

[nbohr1more]

I recall I had to rename the Light Texture for the moon beams in NHAT and the Training map to kill them. But I suspect changing the moon-beam light texture in Gimp then making the material definition that matches the moon-beam one is a bit too much at this point.

 

Wouldn't adding this to the light properties do it?

 

http://www.modwiki.net/wiki/Color_%28Material_stage_keyword%29

 

Yellow:

color 1, 1, 0, 0

 

Blue:

color 0, 0, 1, 0

 

Red

color 1, 0, 0, 0

 

But isn't that what happens in Dark Radiant anyway... (or is supposed to happen)?