• Advertisement

Archived

This topic is now archived and is closed to further replies.

Concatenating strips - can I fool gl*Pointer by overloading operator[] ?

This topic is 5502 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This probably sounds silly, but I thought it was worth asking... I''m working on getting a decent frame rate out of my quadtree terrain, and it''d be handy to draw entire visible nodes as single triangle strips (rather than all the child chunks as seperate strips). Can I pass a pointer to a Vertex class to the gl vertex / texture pointer funcs, and by overloading Vertex::operator[] do my own dynamic strip concatenation? Alternatively if the gl funcs increment the pointer to copy the data, could I overload the ++ operator to the same effect? I''m guessing if the gl funcs use something like memcpy, my ideas are pointless... If thats the case, I figure I can either use NVTriStrip every frame (probably a really bad idea) or just keep lists of vert indices on the parent nodes as well as the leaves (memory intensive). Any ideas?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
No, and no. There is no way that the OpenGL DLL would know of your operator overloading scheme, seeing as it''s a plain C library.

Share this post


Link to post
Share on other sites
Ah well, I thought so. Had to check though, just in case ;¬)

Thinking more on it, it''d probably lead to crappy performance even if it were possible - time spent sorting the strips during the copy would stall the pipeline.

In the end I think I''ll have my leaf nodes register themselves as visible to the top node in that heightmap, and have that object concatenate them.

cheers

Share this post


Link to post
Share on other sites
I remember a short article a while back, I think it was here on GameDev, that showed how to use degenerate triangles to concatenate triangle strips for terrain rendering. I''m too tired to remember how to do it now, but if you can''t find the article or figure something out, I''ll see if I can figure out how it was done and post it.

yckx

Share this post


Link to post
Share on other sites
u can create a single strip out of one chunk, solutio make degenarnt triangles.

btw i stopped using strips for terrain a while ago, on hardware t+l cards the performance benifits aint very much at all.

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Share this post


Link to post
Share on other sites
yckx: thanks, yeah I''ve seen that article. My main concern is whether to do it every frame (to get the largest strip possible for each visible node), or just do it a load time and store extra lists of indices for say 1 or 2 levels in the tree above the leaves. I figure doing this for square chunks should be pretty easy.

This seems to be the best way of getting large strips, while keeping the chunks a reasonable size for frustum culling.

Also, in the comments on the article their seems to be some question of how may degenerate tris you actually need to add, which added to my confusion ;¬)


Zedzeek: Having seen your sceen shots, I''m very interested to know how you do your stuff. Do you use plain old tri lists then? Compiled arrays or not? Do you use VAR? Surely strips will make better use of the post TnL vertex cache?

I''m trying to work out the best way to use strips in my existing code. Seems easy on the face of it, but winding, concatenation and cach size all add complexity.

At the moment I''m using tri lists (no VAR or compled arrays) for each chunk, with a quadtree and frustum culling and get an appallingly bad framerate with a 256*256 heightmap and skydome. ;¬) That said, I still need to play with my camera and view depth to get a good balance. Any tips?


thanks guys,

Dan

Share this post


Link to post
Share on other sites
quote:
Original post by mrbastard

At the moment I'm using tri lists (no VAR or compled arrays) for each chunk, with a quadtree and frustum culling and get an appallingly bad framerate with a 256*256 heightmap and skydome. ;¬) That said, I still need to play with my camera and view depth to get a good balance. Any tips?


thanks guys,

Dan



To speed things up you probably need to use some LOD algorithm, even with a quadtree for culling bruteforcing your way through will give you poor framerates (atleast when the terrains get big). I recommend using geomipmaping (it certainly boosted the performance of my terrain engine)


[edited by - George2 on January 22, 2003 2:27:07 PM]

Share this post


Link to post
Share on other sites
>>Zedzeek: Having seen your sceen shots, I''m very interested to know how you do your stuff. Do you use plain old tri lists then? Compiled arrays or not? Do you use VAR? Surely strips will make better use of the post TnL vertex cache<<

for the terrain + all else i use plain old glDrawElements( GL_TRIANGLES, ... ) no VAR or CVA no strips(i used to use strips but found out with hardware t+l theyre not needed like they once were).

switching to VAR or something else will ultimately have little impact on the frame rate (im fillrate bound)

perhaps youre not geometry limited try this
draw the scene at 800x600 see what the fps
now resize the window to 400x300 check the fps, if the fps goes up lots, then switching VAR (or CVA etc) will have a minimum impact on the fps

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Share this post


Link to post
Share on other sites
George2: Thanks, I''d read it and thought about implementing it in the next iteration of my engine (though with morphing between LOD levels if poss - i can dream!). At the moment I''m having enough hassles with relatively small terrains - I''m figuring I shouldn''t need LOD on a 256*256 (one vertex per pixel) heightmap?

Zedzeek: Yeah, I''m fillrate bound. I expect this as I''m running on a gf2mx200 :¬( the worst fillrate in geforce land. I''d still like my geometry stage to be as fast as poss though, to make the engine more useful generally (eg on hardware other than mine).
As far as the fillrate prob goes I''m only doing multitexturing (overall * detail) but no near-far draw order sorting, so I reckon it''s Z writes that are slowing it in that respect. Unless sampling my overall texture (2*size of heightmap in each dimension) and streching it across the whole terrain is taking too long? From your experience, any idea which is the likely culprit? (or if both which is worse!)

I''ve been so busy coding the quadtree and culling, I''d forgotten about the near-far sorting. Never quite decided whether to implement a general renerer object and handle it there, or just hack it in for the terrain (as thats the main thing that''ll need it) - the old weighing up of time to implement Vs nice and reusable design...

Share this post


Link to post
Share on other sites
>>I''d forgotten about the near-far sorting<<
this will gain about 1-3%, ie not much.

turniong off zwrites for subsequent passes helps a bit better

>>I''m running on a gf2mx200<< ive got one to but ALL cards are fillrate bound the app will most likely also be fillrate bound on a gf4/radeon9700.

personally the best bet is ignore it, stick in a plain glDrawElements or even glBegin(..) .. glEnd() call.
+ then when youre actually finished the app/game whatever in 6 months time then add it in ( a 10 minute job ).
youll be a better coder then i expect.

at the moment now yourve prolly wasted a couple of days on this thing (which can be solved in 10 minutes later) these couple of days would be better spent on another part of the engine. your ultimate aim i expect is to actually finish something? it will take a lot longer if youre getting sidetracked by small things like the above

remember ''premature optimization is the root of all evil''


http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Share this post


Link to post
Share on other sites
Gah! You''re right!

Cheers for the quck slap back into perspective zed.

Add ''premature software engineering'' to ''premature optimisation'' - my quadtree is inherited from and fully integrated with a general scenegraph - looks great and was fun to design/code, but really pretty pointless at the moment ;¬)

Best to get something working, then improve on that.

Still, any ideas on improving framerate when fillrate is the bottleneck? I know in general I should avoid drawing very large or small tris, but I don''t really know how to work out what is likely to slow stuff down in this stage. I''m assuming anything that makes the texture lookup / transformation take longer... but what is that?

I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrain (1 pass, 2 texture units, 1024x768, 32bpp) seems really crappy and I''m wondering if I''m doing anything seriously wrong. I just want to make sure I''m heading in the right direction as it were ;¬)

Thanks again,

Dan

Share this post


Link to post
Share on other sites
I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrain>>Still, any ideas on improving framerate when fillrate is I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrainthe bottleneck?<<

use mipmaps
smaller textures
use texture compression
use lower internal texture formats
turn of zwrites
etc

>> I know in general I should avoid drawing very large or small tris<< <- i dont know this is supposed to help

>>I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrain<<
is pretty bad for gf2mx is this with all the triangles visable?

using plain old vertex arrays u should easily get 60fps for 256x256 tris at that resolution.

r u changing states very often eg binding different textures?


http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Share this post


Link to post
Share on other sites
Thanks zedzeek, I sorted my state changes out and doubled the fps ;¬)

Yeah, the <12fps was drawing all (or most of) the triangles. But it''s not 256x256 tris, it''s 256x256 verts the way i''m doing it = 255x255x2 = 130050 triangles. Does this sound reasonable?

I''ll try sorting the textures next and see how it goes.

Cheers mate.

Share this post


Link to post
Share on other sites

  • Advertisement