cheers;
Jack.
Vertex density and count - how high can I go ?
Author
hi,
I''m designing a landscape engine using Direct3D-IM7...
I''m writing my own lighting engine - so the D3D lighting engine is disabled; does this mean I can squeeze more vertices through the pipeline - or if not; will it be faster?
Second; my landscape is made up of 5000 vertices - in a triangle strip - I have a reasonable computer, 500Mhz/32Mb 3D, is 5000 vertices too high? considering there''ll be players and object on top of this...
Third; The distance between all my vertices in the landscape is "5" - I take its meters.. Should I make this gap smaller?
If you were creating a landscape with 50x50 square on screen, what distance should I place between them?
Lastly; If I make the vertices closer together I can create a more detailed landscape - but how far can I go?
Basically; and tips on writing landscape engines would be extremely helpful...
cheers;
Jack.
cheers;
Jack.
Boy, do those questions sound familiar...I''m right in the middle of designing/improving a landscape as well...Let me try to reply to some of them, but no guarentees...ok?
logically, pre-lit vertices should be faster since less math is required during rendering - but who knows what lurks inside dx7 (and the 3d board). BTW,I''d design for a slower computer if you intend to sell it in the near future - many are still around.
As for the landscape, I''m using global define to set my grid size, currently set at 32 (32x32). It, by the way is surrounded by a 2x grid (64x64) of 2x2 squares. I''m using 2000ft as a square size, resulting in a 25mi radius. I need the distance cause its a flight sim and the pov can be at any altitude.
If you''re ground based, you probably don''t need a large radius, and could focus on more detail (smaller squares). I guess the choice of grid and square sizes is in part experimental. A lot depends on the topology (mountain/desert) and the altitude of the POV. The key is to hide the edge from the user somehow, giving the perception of a continuous world.
I DO recommend setting up global constants or defines for your grid and square sizes - it allows experimentation without recoding.
Hope this helps...Good luck!
logically, pre-lit vertices should be faster since less math is required during rendering - but who knows what lurks inside dx7 (and the 3d board). BTW,I''d design for a slower computer if you intend to sell it in the near future - many are still around.
As for the landscape, I''m using global define to set my grid size, currently set at 32 (32x32). It, by the way is surrounded by a 2x grid (64x64) of 2x2 squares. I''m using 2000ft as a square size, resulting in a 25mi radius. I need the distance cause its a flight sim and the pov can be at any altitude.
If you''re ground based, you probably don''t need a large radius, and could focus on more detail (smaller squares). I guess the choice of grid and square sizes is in part experimental. A lot depends on the topology (mountain/desert) and the altitude of the POV. The key is to hide the edge from the user somehow, giving the perception of a continuous world.
I DO recommend setting up global constants or defines for your grid and square sizes - it allows experimentation without recoding.
Hope this helps...Good luck!
Author
cheers;
What I''ll probably do later in the development is add in some form of fogging - so you cant see the straight edges. But right now it''s not important...
My computer is a 500Mhz chip - But I''m designing for ~266/300 end setup...
y''see, my Savage4 goes at 61fps if I have 1 vertex, and 61fps if I have 5000 vertices - It never seems to slow down; until you pile it with stuff and it just grinds to a halt
Jack;
What I''ll probably do later in the development is add in some form of fogging - so you cant see the straight edges. But right now it''s not important...
My computer is a 500Mhz chip - But I''m designing for ~266/300 end setup...
y''see, my Savage4 goes at 61fps if I have 1 vertex, and 61fps if I have 5000 vertices - It never seems to slow down; until you pile it with stuff and it just grinds to a halt
Jack;
I just up''ed my dimensions to 100x100 from 64x64 (I stated 32x32 above erroneously), and saw minimal degradation in fps. That comes to 20k+ vertices. I''m on a P266 and seeing about 10fps - but I know I need to fix a few things. I''m planning fog too...
Hi
The most usefull thing would be to make the resolution dynamic. If you have all the variables in constants, you could set them with sliders, or even with help of the commandline for beginning.
The problem that you can''t create Arrays with non constant Variables isn''t a Problem. You only need to create your arrays with malloc (don''t forget to free them up in the end).
If you wan''t to make it more advanced, observe the Framerate, and dynamically change your resolution. This is extremly usefull, when you have a game, where sometimes you only see empty landscapes, and in other situations hundreds of units go into combat.
Lars
The most usefull thing would be to make the resolution dynamic. If you have all the variables in constants, you could set them with sliders, or even with help of the commandline for beginning.
The problem that you can''t create Arrays with non constant Variables isn''t a Problem. You only need to create your arrays with malloc (don''t forget to free them up in the end).
If you wan''t to make it more advanced, observe the Framerate, and dynamically change your resolution. This is extremly usefull, when you have a game, where sometimes you only see empty landscapes, and in other situations hundreds of units go into combat.
Lars
Author
I was thinking about something similiar - more vertices in the complex (mountainous) areas; and less vertices in the plains...
That sort of thing can be added later.
The good thing is that there is only ever likely to be 4 players/units on screen at any one time - it aint an RTS with loads of units...
This way I have more time for landscapes and objects...
JAck
That sort of thing can be added later.
The good thing is that there is only ever likely to be 4 players/units on screen at any one time - it aint an RTS with loads of units...
This way I have more time for landscapes and objects...
JAck
Sorry to not be answering your topic, but I just thought I would give a possible theory on something you said.
"y''see, my Savage4 goes at 61fps if I have 1 vertex, and 61fps if I have 5000 vertices - It never seems to slow down; until you pile it with stuff and it just grinds to a halt "
More than likely, you are flipping your backbuffer/primary surface etc. Now if you don''t specify the NOVSYNC flag (and you haven''t disabled monitor syncing at the driver level) your flips will always wait until the Vertical Scanline is at the beginning / end of it''s run. Now if you''re monitor is refreshing at 60hz, you will always get a max of 60fps (or near to it depending on the accuracy of your fps counter/timer) whether you are actually getting 600fps or 62fps. So you see if you are rendering 1 vertex, you may be getting 1,200fps for example, but because your flip''s are synced to your monitor, you will actually only update at 60hz. However as your REAL frame rate creeps down, eventually you will fall under 60fps as the load gets too great.
Try specifying the DDFLIP_NOVSYNC flag when calling IDirectDrawSurface7::Flip and see how fast it REALLY runs.
Sorry for this pointless reply.. =)
Adam "Nutz" Hoult
VB Gaming Central
"y''see, my Savage4 goes at 61fps if I have 1 vertex, and 61fps if I have 5000 vertices - It never seems to slow down; until you pile it with stuff and it just grinds to a halt "
More than likely, you are flipping your backbuffer/primary surface etc. Now if you don''t specify the NOVSYNC flag (and you haven''t disabled monitor syncing at the driver level) your flips will always wait until the Vertical Scanline is at the beginning / end of it''s run. Now if you''re monitor is refreshing at 60hz, you will always get a max of 60fps (or near to it depending on the accuracy of your fps counter/timer) whether you are actually getting 600fps or 62fps. So you see if you are rendering 1 vertex, you may be getting 1,200fps for example, but because your flip''s are synced to your monitor, you will actually only update at 60hz. However as your REAL frame rate creeps down, eventually you will fall under 60fps as the load gets too great.
Try specifying the DDFLIP_NOVSYNC flag when calling IDirectDrawSurface7::Flip and see how fast it REALLY runs.
Sorry for this pointless reply.. =)
Adam "Nutz" Hoult
VB Gaming Central
Author
thats actually useful though
I sort-of knew that - but I''d never really thought about it...
my monitor cant go any faster than 56hz though.... I get between 59 and 62 fps using double buffers; and up to 111 using tripple buffering...
Jack.
I sort-of knew that - but I''d never really thought about it...
my monitor cant go any faster than 56hz though.... I get between 59 and 62 fps using double buffers; and up to 111 using tripple buffering...
Jack.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
