Home
Blogs
Forums
News
Portfolios
Projects
Tutorials
28 users logged in
New? Learn about game development.
Before posting, review our community guidelines.
Follow Us
Chat in the GameDev.net Discord!
Mastodon
Back to Graphics and GPU Programming

Floor renders slower than ceiling

Started by
16 comments, last by MilfredCubicleX 17 years ago
Quote:Original post by jbarcz1
How does performance change if you take the other stuff out and then look at the floor?

The floor, rendered by itself, is slower than all other faces rendered together.

Quote:Original post by lonesock
did you try using the exact same texture (say from the ceiling) for all surfaces?


Yep, to no avail.

I just made another bsp real quick, almost identical to the one that is exhibiting the problem but even simpler (floor, ceiling, four walls) and the floor problem is gone. However, I have another bsp which is much different from these two, but it exhibits the floor problem.

Here's a picture. The top ones are the original problem bsp. The bottom right is the one I just made which has no slowdown. Bottom left is a totally different BSP with huge huge slowdown.

[Edited by - MilfredCubicleX on March 22, 2007 1:41:02 PM]
Advertisement
That behaviour would seem to suggest some issue with your bsp rendering code.
Maybe it is not properly handling complex bsp situations; could it be rendering the floor plane more than once per frame?

I once had an analogous problem with my Portal Engine, where the render pass would end up doing cycles for some situations and end up rendering stuff more than once...
Quote:Original post by haphazardlynamed
That behaviour would seem to suggest some issue with your bsp rendering code.
Maybe it is not properly handling complex bsp situations; could it be rendering the floor plane more than once per frame?

I once had an analogous problem with my Portal Engine, where the render pass would end up doing cycles for some situations and end up rendering stuff more than once...


Hmm, you may be right, the primitive counts seem way off... I will check this out (after physics class)

Yeah.. 100 vertices... something strange.

Ok, i added a light and spawn point to the new scene that didn't have slowdown (but did have an obscene amount of vertices) and the vertices were reduced to 24. However the other bsps have lights and I'm get an obscene amount of vertices for both. Even with only 24 vertices i'm getting the strange floor effect.

It seems that the visible clusters contain duplicate vertices, hence the overdraw..

[Edited by - MilfredCubicleX on March 22, 2007 11:57:01 PM]
Alright, for the extra simple scene, I sent all the vertices to the debug output. To render, there is one index buffer per texture, and the buffer is sorted by visible clusters. The problem is that each cluster holds the same vertex information as the rest of the clusters..

Here are the vertices:
Vertices: 24texture: 0 cluster: 0--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 0--184, -64, 184184, -64, -184184, -64, 184texture: 0 cluster: 1--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 1--184, -64, 184184, -64, -184184, -64, 184texture: 0 cluster: 2--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 2--184, -64, 184184, -64, -184184, -64, 184texture: 0 cluster: 3--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 3--184, -64, 184184, -64, -184184, -64, 184texture: 1 cluster: 0--184, 128, -184-184, -64, -184-184, 128, 184texture: 1 cluster: 0--184, 128, 184-184, -64, -184-184, -64, 184texture: 1 cluster: 0-184, -64, 184184, 128, 184-184, -64, 184texture: 1 cluster: 0--184, -64, 184184, 128, 184-184, 128, 184texture: 1 cluster: 1--184, 128, -184-184, -64, -184-184, 128, 184texture: 1 cluster: 1--184, 128, 184-184, -64, -184-184, -64, 184texture: 1 cluster: 1--184, 128, -184184, 128, -184-184, -64, -184texture: 1 cluster: 1--184, -64, -184184, 128, -184184, -64, -184texture: 1 cluster: 2-184, -64, -184184, 128, -184184, -64, 184texture: 1 cluster: 2-184, -64, 184184, 128, -184184, 128, 184texture: 1 cluster: 2-184, -64, 184184, 128, 184-184, -64, 184texture: 1 cluster: 2--184, -64, 184184, 128, 184-184, 128, 184texture: 1 cluster: 3-184, -64, -184184, 128, -184184, -64, 184texture: 1 cluster: 3-184, -64, 184184, 128, -184184, 128, 184texture: 1 cluster: 3--184, 128, -184184, 128, -184-184, -64, -184texture: 1 cluster: 3--184, -64, -184184, 128, -184184, -64, -184texture: 2 cluster: 0-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 0--184, 128, 184184, 128, -184-184, 128, -184texture: 2 cluster: 1-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 1--184, 128, 184184, 128, -184-184, 128, -184texture: 2 cluster: 2-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 2--184, 128, 184184, 128, -184-184, 128, -184texture: 2 cluster: 3-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 3--184, 128, 184184, 128, -184-184, 128, -184


You can see that the vertices are duplicated over each cluster.. but i don't know why this is. Maybe someone who has run into this duplicate vertices problem can help me.
No Clue
You've lost us, thats getting way too far into the specifics of your code.
Not even sure what you're building...
Quote:Original post by haphazardlynamed
No Clue
You've lost us, thats getting way too far into the specifics of your code.
Not even sure what you're building...

oh well, i'll figure it out eventually
What I mean is.
That in your prior post you've only posted a list of debug output from your program.

We can't tell you anything about what that means, because we don't know anything about the program that outputted it.

Maybe you could try describing what the program does...
then that list of vertices and clusters(whats a cluster?) might mean something to everyone else here...
Uhh sorry, the only part of the program i'm trying to debug is the renderer. The part that is behaving strangely is the bsp rendering. The debug output was from where the program takes BSP information from a quake 3 bsp file, and turns it into a format DirectX can use. I outputted all of the vertex information (namely, the vertices that make up all faces in the BSP) sorted by texture and cluster. To determine visibility, BSP faces are grouped into clusters. There is then a lookup table in the BSP to determine what clusters are visible at other clusters. Much to my dismay, there are many duplicate vertices (and therefore duplicate triangles) in the BSP file. I guess my possibilities are a) the BSP isn't getting compiled correctly (doubt it, i'm using q3radiant, which was what IDSoftware used) b) I'm not loading the information correctly or c) I don't fully understand the file format

Whoops, turns out the answer was c) I don't fully understand the file format.
"Because a face may protrude out of the leaf, the same face may be in multiple leaves." I thought they were tessellated. Problem solved..

[Edited by - MilfredCubicleX on March 26, 2007 2:09:19 PM]

This topic is closed to new replies.

Advertisement

Popular Topics

Aybe One
How do you manage yourself and your time as years pass on? GDNet Lounge
Jikoob
Too many managers? General and Gameplay Programming
ReignOnU
Do your part to stop global warming and climate change GDNet Lounge
aigan
The promise of freedom in story games Game Design and Theory
robertrobert
Facebook Ads for sales on steam, does it work? Games Business and Law
AliAbdulKareem
Understanding the wavy-like shape in alpha-testing magnification for text rendering Graphics and GPU Programming
Advertisement

Recommended Tutorials

avenkov
Game i18n via IME General and Gameplay Programming
Myopic Rhino
Unity Summer of Code Post Mortem: Detonator Interviews
Myopic Rhino
Radiosity Methods Graphics and GPU Programming
gdarchive
Open Source and the Gaming Industry Business and Law
Myopic Rhino
The Two C Game Design and Theory

Reticulating splines

About GameDev.net
Community Guidelines
Terms of Service
Privacy Policy
Contact Us
Copyright (c) 1999-2024 GameDev.net, LLC
Back to Top