Actually, they're not being filled, so it would be faster. Not as fast as using a COG to flag them as invisible at that distance, though.

Are you sure it does it for 3dos , too. I always thought it's only doing it for sectors, rendering all the 3dos in the visible ones...
I may be wrong, though.

JK may do frustum culling but I'm fairly certain it doesn't do occlusion culling for 3dos.

You're probably right about that. Sige would be the person to ask, really.

This is all beside the point... I'm certain Spiral doesn't want the other side of the Colosseum to disappear when looking across to the other side. If anything like that is done, I'd say LOD models are the only way.... and I don't envy the man with that task.

Truth is, 3dos are always rendered if their assigned sector is viewable.... even if the 3do itself cannot be seen from such an angle. The 3do is no longer rendered the moment the assigned sector is no longer viewable.... simple as that. It's the same reason dynamic lights "flicker" off when their containing sectors are no longer rendered... even tho their light range spans many sectors.

Because drawing the texture to each surface is FAR more process intensive then drawing the architecture. It's an easy solution for the cog impaired (like myself).

They are most likely sent to the renderer, but there's no way anything outside of the player's viewing frustum is rendered.

Wasn't it you who just yesterday saw a IM Mine 3do in an overlapping sector that shouldn't have been rendered, but it was anyway? Reason being, a piece of it's containing sector was visible, so the 3do was rendered just the same.

Yeah, but it was within the viewing frustum. Otherwise I would have never seen it and it wouldn't have mattered...

I disagree.... but for the sake of keeping this thread on track, I look forward to this discussion on #jkhub.

so then.. cut up the sector?

Stop being dumb halucid. Triangles outside the viewing frustrum are culled; if not by JK, then by directx. They can't be rendered, because they are outside the confines of the screen.

Well, as long as they are being sent to the "culler", there might be some fps to gain when splitting the sector up, aye? Because doing so would ignore the 3dos in invisible sectors at a much earlier time, right?

Unlike you, Isuwen, I have enough humility to handle being wrong from time to time. The truth is, I'm only basing my arguement by what I know as a mapper, not a mathematician. If a 3do is in a sector, but it shouldn't be rendered since it's out outside the frustum, it's still rendered as long as it's containing sector is within the frustum (just like dynamic lights are). I've seen this with my own eyes not 2 weeks ago. To test this, put a 3do in an overlapping sector, look into the sector from off angles, and see for yourself.

I'm going to have to take halucid's side on this matter. Being another fellow mapper.

Yeah, Halucid, you saw it because it was still inside the view frustrum. You know what that is, right? It is litterally defined as the volumn of space you can see on the screen. If it's outside the frustrum, it's not on the screen, period. Now, wether or not JK will cull the whole object (which is fast) or individual triangles (which is slow), is a valid discussion. You cannot, however, claim an object outside the view frustrum is being 'rendered'.

There's a fundamental difference between what the CPU and GPU process to be rendered and what is actually rendered to the screen in 2D. The data that is sent to the screen is what effects your FPS directly (though your FPS is indirectly effected by your CPU and GPU ussage, if they are both high, it could result in a delay in processing and thus a lower FPS). This would include ONLY the surfaces of a 3do that is visible on screen. It would also include ONLY the effects of a Dynamic Light on a surface that's on screen and not the DL.3do itself (which may be off screen).

Yes Isuwen, I know what frustum is... carefull dude, I'm one of the last who still respect you. Condescent has the power to change that.

My beef isn't really with viewing frustum so much as JK's occlusion culling anyway. For instance, say you're looking at a solid wall. This wall has sectors with 3dos beyond it. With cell-based occlusion culling, these 3do's should be culled.... but they aren't always. They are rendered just the same. You can distinctly see the drop in framerate.

Once again we're getting too far off the point. Poor Spiral just wants to know what he can do to up his FPS, and here we are bickering about visibility aglorithms and rendering behavior! Oh, the shame.

On this matter, I still say cleaving up the big sector is Spirals best option... even tho JK's occlusion culling sucks.

I strongly disagree because if he's looking at it, what difference will it make?

My "Cell-to-not-rendered" technique is the best for the cog deffecient (like myself). It's also a "Quick-N-Dirty" fix for the time being. Nothing fancy, just something to up the frame rate while he's still developing the level.

I'm refering to the parts inside the colosseum corridors, not looking across to the other side.

I am open to ideas as to how to increase framerate when looking across the arena, but I know a ranged vector rendering system or phasing textures are NOT something Spiral would be willing to do. Why make such beautiful architecture only to have half of it disappear at a certain range?

As I said several posts back, lower poly LOD models are really the best solution for this. For example, at a far LOD distance, have it so the 3do "slices" that are all ready made switch to a "facade" model of the other side of the colosseum (by removing all of the inner corridors that wouldn't be seen from such an angle anyway). The player would never notice the graphical change this way, and the FPS should increase greatly.

This, in conjunction with strategic sector cleaving, he should have and even higher FPS in side the colosseum's inner corridors.

Ranged would be wrong. But why not make it sector-controlled. I mean, there are certainly situations where a building is completely hidden by another building. Why render this hidden building? Just cleaving the sectors up doesn't help either, because you can still see the sector of the contained building (3dos do not block visibility in JK), so it will still be rendered. But I'm sure it should be possible to define sectors, wherefrom it's impossible to see the building. This calls for a variant of GBK's sector-based thing creation system (maybe with a change from creation/destruction to show/hide).

OR he could make the colosseum out of a hybrid of sector geometry and 3DOs, like what would be PROPER.

Doesn't that usually lead to lighting problems?

Not if you've already commited to all dynamic lights anyway.

I'm not sure if you understood what I wrote at all, bud. I think you thought I meant cleaving his sector up into a pie, and still leaving all of his adjoins intact. I don't mean that at all. I meant more of a "web" style of cleaving, not a "pie". For example:



Spiral's would have to be more complex than this... this is just an example. The faces that have been selected blue should be unadjoined, so occlusion culling wont render whats behind them. These non-portal surfaces will of course be the ones behind the solid walls of the inner corridors. This will make colosseum 3dos behind them not rendered. Without unadjoining, cleaving alone will only lower framerate.

This in conjuction with LOD fracade models (for when looking across to the other side of the arena) will work fine. I promise.

Here's a non-wireframe example:

Well, you said ranged is what he wouldn't want, and I was just trying to support that. The thing you are showing is similar to how I meant it. Except, I don't get the whole unadjoin stuff. I mean, unadjoining leads to either a hall of mirror or a solid wall...and you think this is cool :p?

The unadjoins would only exsist behind the solid walls of the inner corridors, so yup!