FRamerate help!!

[RandomMonkey]

I have just completed the beta version of my map, GOOd n EVIL (http://www.geocities.com/darksquirreldude/index.html for more info), but eh framerte is horrible. Does anyone kno any tips to help speed it up besides caulk?

[lauser]

If you look at some of the default maps for JK2 you will notice that they hardly use caulk. I mean the authors are pretty careless about how they use it. Its usually only to cut down on the compile times. However, making STRUCTURAL brushes into DETAIL can hinder good performance. Especially if you have lots of open spaces. If you have a large OPEN space try to break it up with either Structural brushes or big models like x-wings or tie fighters. I have alot of experience in this area so take my advice when building a map. Stay away from GIGANTIC OPEN SPACES. OR HUGE SKYBOXES around the outside of your map.

 

You can use HINT brushes but they are suited mostly to hallways. If you use STRUCTURAL brushes all on the outside of the map and maybe one or two large ones in the middle and the rest detail you should get the max framerate.

[RandomMonkey]

ty very much, as I do have alot of open area with detail in it. Anyways what are hint brushes and how do they work?

[lauser]

Hint brushes are kind of like a system NO DRAW. Its a shader in the SYSTEM textures you can use in a corner of a hallway to improve framerate. It basically fools the engine into thinking there is nothing beyond the corner when really there is.

 

All you would do is put a TRIANGULAR brush filling the entire hallway in the corner and cover it with hint.

[wedge2211]

I keep losing that hint brush tut out there...ah well. Emon, if you happen to glance at this thread...

 

Hint brushes are NOTHING like nodraw. Nodraw has NO effect on compiles--that's it's purpose. It is a spot of nothingness, to go on unseen surfaces of water or flares or forcefields or stuff like that (usually transparent stuff). A better way to think of hint is like an invisible, nonsolid structural brush.

 

The questions you are asking, about detail and struct brushes, open areas, and hint brushes, require a good deal of explanation about the VIS process, that the RichDeisal tutorials do not cover--or are incorrect about. Here's the basic way it works:

 

VIS's job is to split the map up into bits, so that the game only has to draw the visible bits and it won't worry about drawing stuff that's far away or around a corner or behind a closed door. Two names that are used kinda interchangeably by people for these "bits" are "leaf nodes" and "portals" (though these terms really have slightly different meanings). A "split" is the plane that separates two leaf nodes.

 

Leaf splits are only created by structural brushes. The splits extend in all directions fromt he planes of the struct brushes--so if you have a struct pillar in the middle of a room, the splits will go all the way to each wall or until they encounter another split. This is how VIS divides maps into leaves. Detail brushes are IGNORED by VIS--they create no splits.

 

The game engine only draws those leaves that are visible from the current position of the player. Visiblity in game is determined by the presence of struct brushes, not splits. Detail brushes are "see-through." Remember the more the game has to draw, the lower FPS goes. So two things could cause low frame rates: lots of leaves being drawn, or a few big leaves being drawn. There's not much you can do about big areas except try to seal them off from the rest, but you can force the game to stop drawing extra leaves with hint brushes.

 

Hint brushes force a leaf split from each face that is textured with system/hint. So if you position a hint brush properly (see the tut that I hope Emon will post), you can force the game to add a new leaf that separates the spots where players can stand from the rest of the map. Best way to explain this is pictorally...so I won't try to talk it through.

 

Another thing is area portals. Put system/areaportal brushes inside all your doors. That way, the doors will act like struct brushes when closed (and block visibility).

 

Hope that long-winded thing helps.

[lassev]

Now, here's one link to a hint brush tutorial:

 

http://fps.brainerd.net/hintbrushes.htm

 

or if it's not enough, try:

 

http://www.nibsworld.com/rtcw/tutorial_detail_and_hint_brushes_part1.shtml

 

 

Well, once you master the basics of hint brushes, you'll notice trial and error is the way to go. But hint brushes don't do any magical tricks, not like good old area portals...

[lauser]

I agree Lassev. Thanks for the info guys. I forgot what the basic idea was so was just guessing.....hehe..

[Emon]

A better way to think of hint is like an invisible, nonsolid structural brush.

Er, that isn't much better than like nodraw. Hints create additional BSP leaf nodes wherever the hint texture touches.

 

 

VIS's job is to split the map up into bits, so that the game only has to draw the visible bits and it won't worry about drawing stuff that's far away or around a corner or behind a closed door. Two names that are used kinda interchangeably by people for these "bits" are "leaf nodes" and "portals" (though these terms really have slightly different meanings). A "split" is the plane that separates two leaf nodes.

Uh, not really. A leaf node is a volume of space that has no structural brushes in it. If you made a single cube with nothing in it, that would be one leaf node. Portals are what connect leaf nodes, you might think of them as planes. A split is a portal, a portal is a split.

 

 

The game engine only draws those leaves that are visible from the current position of the player. Visiblity in game is determined by the presence of struct brushes, not splits.

False. Portals, or splits, are what determines what should be rendered. Any portals that can be seen by any portals in the player's viewport (what you would see if portals were visible) have leaf nodes on either side drawn.

 

So two things could cause low frame rates: lots of leaves being drawn, or a few big leaves being drawn. There's not much you can do about big areas except try to seal them off from the rest, but you can force the game to stop drawing extra leaves with hint brushes.

Well the first part is true, a lot of leaves being drawn will lower framerate. I don't know where you got the second part, though. A few big leaf nodes is no different than a few small leaf nodes. Deep down in the engine's rendering code is a line something like "glVertex3d(X, Y, Z)" which draws a vertex. After three of these, it creates a triangle (unless polygon rendering is used, but don't worry about that). It doesn't care how big or small the triangle is, it's all the same. Just like how plotting (1, 1) on a Cartesian takes no less brainpower than plotting one on (2, 2). At least for most of us.

 

 

Another thing is area portals. Put system/areaportal brushes inside all your doors. That way, the doors will act like struct brushes when closed (and block visibility).

Yes, make them some size thinner than your door, but not thinner than two units. Nothing should be smaller than two units. Except that as I mentioned above, it's not struct brushes that do this. I'm not entirely sure how areaportals affect the compile process, but I know everything behind one when a door is closed is not rendered.

 

As previously posted, this is the hint tutorial he was referring to: http://www.nibsworld.com/rtcw/tutorial_detail_and_hint_brushes_part1.shtml

 

It is, by far, the best tutorial on BSP and VIS I have ever seen.

[lassev]

Although it's not relevant to MP maps, but in SP you can also play around with the script command Adjust_areaportals. It allows you to use areaportals with, for example, func_statics. Areaportals work just fine automatically with doors, but with other entities it can give you nice HOM (if you don't use the command mentioned above).

[RandomMonkey]

ok... so would it make sence if I have a curved ceiling to cover the curve area with hint... also can you still move into space with hint in it, or does it work liike clip in that sence... unless it say in the tuts I'm about to read...

[wedge2211]

Originally posted by Emon

Uh, not really. A leaf node is a volume of space that has no structural brushes in it. If you made a single cube with nothing in it, that would be one leaf node. Portals are what connect leaf nodes, you might think of them as planes. A split is a portal, a portal is a split.

Okay, thanks for the terminology corrections.

 

False. Portals, or splits, are what determines what should be rendered. Any portals that can be seen by any portals in the player's viewport (what you would see if portals were visible) have leaf nodes on either side drawn.

How is this different from what I wrote, if struct brushes determine what is visible (ie, portals behind struct brushes are not in the player's viewport)? Sorry if I'm mixing things up...

 

 

Well the first part is true, a lot of leaves being drawn will lower framerate. I don't know where you got the second part, though.

I guess I made the assumption that in a large leaf node, there will be lots of "stuff" (this is certainly true when I map ). So okay, the more stuff is drawn, the lower FPS is. Same difference.

 

Thanks for clarifying, Emon, and providing that link. Compiling process isn't my forte, so it's good to have a guru like you around on the boards. Every else, I'm sorry if this has confused you at all.

[Emon]

Originally posted by wedge2211

How is this different from what I wrote, if struct brushes determine what is visible (ie, portals behind struct brushes are not in the player's viewport)? Sorry if I'm mixing things up...

 

You're saying that a structural brush will block visibility, but that's not always true. Anyone who's done serious level design and taken a look at their map with r_showtris 1 after placing some new struct brushes will testify that this isn't at all true.

[wedge2211]

Hmmm, I guess I should just not go too deep into how it works. I'm gonna stop answering compiling questions for my own safety...

[Eldritch]

Originally posted by Emon

Anyone who's done serious level design and taken a look at their map with r_showtris 1 after placing some new struct brushes will testify that this isn't at all true.

 

Ouch, that's pretty close to a personal shot, Emon. Let's try and keep it above the belt now, m'kay?

[Emon]

Eh? No it's not. I'm just saying anyone who has done a lot of level design and examines their level with developer cvars like r_showtris will know that. If I wanted to insult him I would just insult him, not merely state the truth.

[Eldritch]

I know Wedge well enough to assure you that he uses r_showtris, Emon.

 

I've used it myself, but until I read that tutorial on hinting (saw the link for it a few months back) I didn't understand the concept either - and I had used r_showtris before.

 

My point is only that you should try not to make such sweeping generalizations, since it's obvious that not everyone can discern such detailed information about VIS simply from using developer cvars.

[Shotokan]

K wait a sec.... When do you make a brush detail or structural again? Sorry I forgot.

[Karshaddii]

A lecture on improving FPS

By ME!

 

A good rule by the thumb is to make every brush that does not touch the void a detail brush.

 

Of course there are many, many, times when you are going to want to divide rooms with walls that do not touch the void---

 

Basically, all I can say is this:

 

Right angles are your friend.

 

Build your map on right angles, make lots of angled hallways connecting your big rooms. Make ALL rooms cubic--THEN go back and add detail to them to make them seem angled, curved, round, or whatever.

 

Avoid excessive uses of water type-shaders and dynamic fog. And if you have to go heavy on them, make sure it is the central focus of your map.

 

Use caulk scrupulously. (no, I dont have a clue how to spell it) The less textures a computer needs to process the better--this is true especially if the player is using trillinear filtering.

 

Screw nit-picking details. Sure, they are aesome, and made games like Half-Life what they are, but I guaruntee you a good 80 percent of players wont even notice. A good rule is to make all detail the CENTRAL focus of a room.

 

Use those flat colors in the /color texture directory. Flat colors are hundreds of times simpler to process. And example on their use:

 

You have a fog filled canyon in which you can barely see the bottom. Rather than paint the bottom in sky, mud, rock, water or whatever, use a similar flat color such as black or white. This, believe it or not, helps tremendously on those huge, open brushes.

 

Cut down on those effects, again, making them the central focus of the area. Most people don't want to look at fifteen torches in a row anyways.

 

Dynamic light effects in the q3 engine never look like they should--excluding , of course, the strobing red warning light. So try not to use them...again...unless they are the central focus of a room. (notice a pattern in advice yet?)

 

You all know this, but just a reminder, spawn those NPCS, don't just place them ahead in the level waiting for the player. When the player opens the portal with the NPC's in it, things are going to slow down.

 

Use area_portals to seal off different portions of the map, especially rooms with sounds and effects. Also use them to portal up areas that normally would be exposed.

 

Some of you expertes might not even know this, but area_portals are also the ONLY way rooms with skyboxes as their structural brushes can be connected without exposing the brushes through the sky of the adjacent room. Use this to create simulated large, outdoor areas.

 

For some reason, patch meshes slow down JO more than models do. I have run several tests, and JO likes a model such as tree_sidehillb much better than a simple patch mesh with only 10 vertices. This makes no sense to me, but its the truth. Go test it in radiant yourselves. S use models to pretty up your map rather than patch meshes--or brushes. Rather than make a bumpy ground with a patch mesh--learn gensurf and do it that way.

 

Rather than having an onslaught of enemies pour at you at once, consider spawning them with scripts as others are killed so it gives the EFFECT of fighing hordes of enemies at once without actually proccessing hordes of enemies.

[Emon]

A good rule by the thumb is to make every brush that does not touch the void a detail brush.

That is an absolutely horrible rule of thumb. RichDiesal has or had no clue what he was talking about when he said this. Making everything detail completely defeats the purpose of BSP, as the entire level will be rendered at once. This speeds up compile times, but will drop your framerate exponentially.

 

Right angles are your friend.

 

Build your map on right angles, make lots of angled hallways connecting your big rooms. Make ALL rooms cubic--THEN go back and add detail to them to make them seem angled, curved, round, or whatever.

 

Horrible advice again. I don't even know what to say to this. It's a waste of time and will probably result in a slower, uglier map.

 

Avoid excessive uses of water type-shaders and dynamic fog. And if you have to go heavy on them, make sure it is the central focus of your map.

Fog isn't dynamic, and you shouldn't avoid them, because they are faster than most people think. Maybe back in Quake III when people had Voodoo 3s, fog was a problem, but it isn't anymore.

 

Use caulk scrupulously. (no, I dont have a clue how to spell it) The less textures a computer needs to process the better--this is true especially if the player is using trillinear filtering.

It's not textures that are rendered, not how you are thinking, it's triangles. Caulking isn't as necessary anymore because Q3Map2's autocaulk is quite reliable, however I still caulk everything, just in case.

 

Screw nit-picking details. Sure, they are aesome, and made games like Half-Life what they are, but I guaruntee you a good 80 percent of players wont even notice. A good rule is to make all detail the CENTRAL focus of a room.

Absolutely horrible. Small details are what set the atmosphere for a level, which can contribute enormously to the gameplay and replayability value. 80 percent of players won't notice? That's crap! The "nit-picking" details of livingdeadjedi's maps are what made them so popular. Unfortunately, his maps are also unoptimized and very slow, and are rarely play tested, but that is a different story. And making all the detail the central focus isn't so much bad as it is just wrong. The central focus should be detailed, of course, but every other part should be equally detailed as well. This is how the level design of games like System Shock 2 and Deus Ex have become legendary.

 

Use those flat colors in the /color texture directory. Flat colors are hundreds of times simpler to process. And example on their use:

 

You have a fog filled canyon in which you can barely see the bottom. Rather than paint the bottom in sky, mud, rock, water or whatever, use a similar flat color such as black or white. This, believe it or not, helps tremendously on those huge, open brushes.

No, it does not. Unless the engine is using a flat color rendering method on a surface, perhaps defined in a shader, it won't be any faster (and there is no way to do this in a shader, and if there was, performance increase would be trivial at best). I don't know where you got this poppycock idea from, but it isn't true. When OpenGL renders a texture to a surface, it doesn't care what color the texture is. It loads each pixel, and stores the color data for each pixel, reguardless of whether or not the color data is that of rock or that of solid blue.

 

Cut down on those effects, again, making them the central focus of the area. Most people don't want to look at fifteen torches in a row anyways.

I sort of agree, but effects can add to the atmosphere in unspeakable ways. Steam coming from pipes or under the grating on the floor is an excellent touch. A grand hallway with torches lining the wall can create a magnificant sight.

 

Dynamic light effects in the q3 engine never look like they should--excluding , of course, the strobing red warning light. So try not to use them...again...unless they are the central focus of a room. (notice a pattern in advice yet?)

If you mean lightstyles, those look perfect, and are flawless. They again add a great effect to something like a fire or a flickering candle, or a warning light. Performance loss is, again, trivial.

 

You all know this, but just a reminder, spawn those NPCS, don't just place them ahead in the level waiting for the player. When the player opens the portal with the NPC's in it, things are going to slow down.

I agree that NPCs should be spawned only when they can be seen or affect the player, but what do you mean, "opens the portal"? Portals are never opened.

 

Use area_portals to seal off different portions of the map, especially rooms with sounds and effects. Also use them to portal up areas that normally would be exposed.

Or you could just use structural brushes and do it the proper way.

 

Some of you expertes might not even know this, but area_portals are also the ONLY way rooms with skyboxes as their structural brushes can be connected without exposing the brushes through the sky of the adjacent room. Use this to create simulated large, outdoor areas.

I'm not sure what you're talking about here... Maybe you mean having an L shaped building with a window that can see other parts of the L structure, and even with a sky shader you can still see the other surfaces through it? Areaportals might work, but the proper method is to actually construct the outside of the building. It would look stupid to look out a window and instead of seeing a massive building, see some clouds.

 

For some reason, patch meshes slow down JO more than models do. I have run several tests, and JO likes a model such as tree_sidehillb much better than a simple patch mesh with only 10 vertices. This makes no sense to me, but its the truth. Go test it in radiant yourselves. S use models to pretty up your map rather than patch meshes--or brushes. Rather than make a bumpy ground with a patch mesh--learn gensurf and do it that way.

This is because patches are somewhat dynamic. You've got a mathematical equation that describes the way the patch is, and the engine figures out how many iterations of polygons, how smooth to make it, depending on how close or far you are. This is fixed with Q3Map2 by using -patchmeta in the BSP stage, and optionally -subdivisions N in the BSP stage to reduce polygon subdivisons on the patches, which makes them faster but less smooth. The default value is eight, increasing numbers decrease the quality of patches.

 

Rather than having an onslaught of enemies pour at you at once, consider spawning them with scripts as others are killed so it gives the EFFECT of fighing hordes of enemies at once without actually proccessing hordes of enemies.

Perhaps, but fighting half a dozen enemies at once then waiting for another half dozen to come at you isn't nearly as fun as fighting two dozen at once. If the enemies are coming at you from a choke point in the world, then this could work, but if you're supposed to take on a platoon of guys at once, you don't have much of a choice.

 

 

I'm not trying to be mean or put anyone down, but I'm seeing a lot of false information being spread in this thread. False information is very bad. It's probably not this guy's fault he thinks like this, it's probably from horrible tutorial sites like RichDiesal's which have given him a poor understanding of how the engine actually works.

[Karshaddii]

Sigh, it's only nooby help, Emon.

 

And not intended for your advanced train of mapping thought.

 

The flickering styles in dynamic light looks incredibly fake, and all it does to a map is induce siezures. The lights turn on and off at different speeds...in real life the light INTENSITY varies, not completely fades into nothing and back.

 

Of course you don't make EVERY brush that touches the void a detail brush--the computer would then render everything. But think noob, how many noobs do you know that have multi-portaled rooms? None, they all build single portaled rooms.

 

As for building on right angles....I don't know what your thinking when you say this is bad advice. You dont know the first thing about level design if you say otherwise, though it is fair to say that I may have been unclear. How does portaling work? How about vis? Leaf nodes? Can you say 90 degrees? All of Raven's maps are built on right angles--if they weren't, then two rooms would load at the same time when entering the new room causing a large drop in framerates. Thats why I say build right angled hallways separating large rooms--this way you dont have to make silly doors that take away atmosphere of a outdoor level or a level where there shouldn't be doors, like city streets. And I don't mean by this build blocky, ugly rooms. Use detail brushes to make wierd angles, patch meshes to implement curves, and a model or a prefab here and there to make atmosphere.

 

Fog. I said DYNAMIC fog---not a fog shader. Once again, trying to be a hotshot just overrun what I was trying to say. Dynamic fog is an effect widely used in FPS's. And it DOES cause slowdown.

 

About spawing NPCS....you said that it might not be as interesting killing six, then watching another six spawn. Emon, Emon, use some imagination. Example, a T hallway. Fight and oncoming slaught of stormies that spawn on the left and right bar of the T. This way you never see them spawn, and you fight hordes at the same time. Gimme a break, man!

 

"Or you could just use..."

Dear George Lucas....what the HECK do you think area_portals are for...I SAID EVERY NOW AND THEN and plus I mentioned SOUND EFX!!!! The lighting portion of the compiler will go faster and the sounds wont get processed until the exact moment you enter the room!!!! It's mainly for the compiler! Now I know your just getting on my case for kicks!

 

"I don't know what your talking..."

Think GROUND and sky man, not just buildings....what about a swamp???

 

OK, about my "popycock" idea about flat shade textures. Ok, whatever...I'm sure processing a high-def repeating texture with millions of colors on a brush about 1000 units in size is faster or just as fast as a texture composed entirely of ONE color. Uhum...thats why advanced 3d models and animaters build their models in flat shades and not fully textured skins...

 

DIDNT I SAY NIT-PICKING DETAILS? Not subtle, atmospheric details? Not Enviroment accenting details? Not genious touches of realism? Not Artistic touches? Not architecturally impressive yet not overly ostentaious details? First of all we are talking about STRUCTURAL tips here. In Half-Life if the a room grid was off by one unit they would toss the room away and redo it until it was perfect, even if a trained human eye could barely pick it up. Avoiding being this scrupulous can make the buildwork of the map go much much faster. I was not talking about steam rising from coffee cups or cool lil' touches of realism here. Please READ whay I say before flaming indiscriminately.

 

Thank you.

[Emon]

First of all, when you make a page that fills up a guy's screen who runs at 1600x1200, you do not have to post it eight times.

 

Sigh, it's only nooby help, Emon.

 

And not intended for your advanced train of mapping thought.

This does not justify spreading of false information which he will think as true, and then use it as a basis for the rest of his mapping career. Any teacher will tell you that you don't teach someone the wrong information and then teach them the right things later.

 

 

The flickering styles in dynamic light looks incredibly fake, and all it does to a map is induce siezures. The lights turn on and off at different speeds...in real life the light INTENSITY varies, not completely fades into nothing and back.

You obviously have not seen all of the light styles. In many the intensity changes. You also are probably not aware that lightstyles can be overridden via worldspawn.

 

Of course you don't make EVERY brush that touches the void a detail brush--the computer would then render everything. But think noob, how many noobs do you know that have multi-portaled rooms? None, they all build single portaled rooms.

That's a big load of **** if I've ever seen one. There are many mapping newbies who are capable of professional work. The following screenshots are by Sine_Nomen and AKPiggot, both newbies to Q3 based editing. They speak for themselves.

http://massassi.net/ec/images/9093.jpg

http://www.massassi.net/ec/images/11670.jpg

 

As for building on right angles....I don't know what your thinking when you say this is bad advice. You dont know the first thing about level design if you say otherwise, though it is fair to say that I may have been unclear. How does portaling work? How about vis? Leaf nodes? Can you say 90 degrees? All of Raven's maps are built on right angles--if they weren't, then two rooms would load at the same time when entering the new room causing a large drop in framerates. Thats why I say build right angled hallways separating large rooms--this way you dont have to make silly doors that take away atmosphere of a outdoor level or a level where there shouldn't be doors, like city streets. And I don't mean by this build blocky, ugly rooms. Use detail brushes to make wierd angles, patch meshes to implement curves, and a model or a prefab here and there to make atmosphere.

No, it is you, sir, that know nothing about the vis process if you say it works off 90 degree angles. 90 degree angles are commonly used in hint and vis tutorials because they are very easy to understand, and demonstrate the concept very well. Go tell John Carmack that his vis code relies on 90 degree angles, and he will laugh in your face. Go tell ydnar, that man who wrote the compiler you use, that his vis process relies on 90 degree angles. Again, he will laugh in your face. If you'd like, I can get him to post here and tell you this. Raven's levels probably are based on 90 degree angles simply because Raven does, well, let's say, not have the greatest level designers in the world.

 

Fog. I said DYNAMIC fog---not a fog shader. Once again, trying to be a hotshot just overrun what I was trying to say. Dynamic fog is an effect widely used in FPS's. And it DOES cause slowdown.

Dynamic fog? What exactly do you mean by this? The word dynamic simply means not static, it can be changed. In the case of fog, it would mean that the fog could do things like move or change color. Some of this may be possible in JO by simply moving a fog brush, but apprently you are talking about something different. Please, share what you mean by "dynamic fog" so that I can better discuss the topic with you.

 

About spawing NPCS....you said that it might not be as interesting killing six, then watching another six spawn. Emon, Emon, use some imagination. Example, a T hallway. Fight and oncoming slaught of stormies that spawn on the left and right bar of the T. This way you never see them spawn, and you fight hordes at the same time. Gimme a break, man!

Well of course. But what if you want to go into the point where they spawn? This becomes a problem. If you restrict the player from such an area where enemies are clearly coming from, it reveals the illusion to the player, and makes it look cheap, which can ruin the experience.

 

"Or you could just use..."

Dear George Lucas....what the HECK do you think area_portals are for...I SAID EVERY NOW AND THEN and plus I mentioned SOUND EFX!!!! The lighting portion of the compiler will go faster and the sounds wont get processed until the exact moment you enter the room!!!! It's mainly for the compiler! Now I know your just getting on my case for kicks!

Sound is always processed, areaportals don't stop them. They may stop you from hearing it, it doesn't mean it isn't processed. The proper way to stop sound from being processed, which takes an incredibly trivial amount of CPU power I might add, is to use triggers. And I am not getting on your case for kicks, as I already said, I'm just trying to stop the spread of false information. It's not your fault, I am not holding anything against you, you have simply been misinformed, just as I was several years ago when I started mapping.

 

 

"I don't know what your talking..."

Think GROUND and sky man, not just buildings....what about a swamp???

Uh, I'm not sure what you are saying. I didn't know what you meant before, which is why I threw out a random situation like that, based on what you told me. If you clarified what you meant, this wouldn't be a problem.

 

OK, about my "popycock" idea about flat shade textures. Ok, whatever...I'm sure processing a high-def repeating texture with millions of colors on a brush about 1000 units in size is faster or just as fast as a texture composed entirely of ONE color. Uhum...thats why advanced 3d models and animaters build their models in flat shades and not fully textured skins...

You don't understand how the actual rendering works. What experience do you have in programming of 3D engines? Any? I have made my own, I know that a solid colored JPEG is no faster than a detailed JPEG unless you instruct the API to render it in a solid color mode, something you would need a shader to do in JO, and something that does not exist in JO. Thus, a solid colored JPEG is rendered exactly the same as a detailed one because the engine doesn't know the difference. Oh, and you are wrong, advanced 3D models and animators used incredibly detailed skins. Examples are any video games or movies.

 

DIDNT I SAY NIT-PICKING DETAILS? Not subtle, atmospheric details? Not Enviroment accenting details? Not genious touches of realism? Not Artistic touches? Not architecturally impressive yet not overly ostentaious details? First of all we are talking about STRUCTURAL tips here. In Half-Life if the a room grid was off by one unit they would toss the room away and redo it until it was perfect, even if a trained human eye could barely pick it up. Avoiding being this scrupulous can make the buildwork of the map go much much faster. I was not talking about steam rising from coffee cups or cool lil' touches of realism here. Please READ whay I say before flaming indiscriminately.

Well "nit-picking" is not exactly a specific, defined term, it is slang, and can have many meanings. It also depends greatly on personal interpretation. Knowing you and the work I have seen from you and it's lack of what I consider true detail, I assumed you meant worldly and atmospheric details. This would have been avoided if you used specifics and defined what you meant instead of assuming everyone thinks the way you do. And how do you know that about Half-Life? Have you spoken with the level designers on this matter? And I have not flamed you, sir, if I was flaming you I would be outright insulting you in the interest of causing trouble. If you cannot take the simple fact that you have been proven wrong in a discussion, then perhaps you should leave.

[lauser]

Sorry guys I don't mean to doubt your ability but, I've looked at the default Raven maps and they are designed quite well. If you look at the outside of these maps they look to be only 70% caulked. And they get excellent framerate. Some even less.

 

For instance because I can use the Academy MOD to transport myself outside DEFAULT M/P maps I can see where CAULK was used and where it wasn't. Or yes even NO CLIP...LOL. Are we talking about S/P and M/P or just S/P? I would love to get ahold of a decompiler so that I could see the REAL map file......oh well.

 

And regarding PATCH meshes. I built an entire ship that you can move in and out of with patch mesh. My framerate is lower in this area but of no real concern. I mean I maybe lose 20-25FPS in that area so it seems fine to me.

 

My point is I here lots about don't do this and don't do that if you want the best performance. I do agree with many things you guys have to say, but I can see when I build maps that some of these things just don't seem to apply. Is it the comp you use? Is it the way or the order you compile? Is it the way the comp you're using today is feeling? One has to wonder.

Currently I'm having major problems with my GTk. It seems to have a mind of its own and will work only when IT feels like it. Very frustrating!

Anyways, I just thought I would put in my 2 cents. I don't know half the stuff you guys do.