|
jadams
|
 |
« on: 2006/11/13 20:07:57 » |
|
WHat difference (if any) in performance have you guys seen between the xna engine and the managed engine?
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
|
« Reply #1 on: 2006/11/13 21:47:37 » |
|
Well, being that I haven't yet thrown together any FPS stuff for the XNA version, I haven't really got much data for you here. It all seems to be running as smooth as it has in the past though. You notice any differences at all chronix?
|
|
|
|
|
Logged
|
|
|
|
|
Chr0n1x
|
|
« Reply #2 on: 2006/11/14 01:07:59 » |
|
No noticed difference here, everything runs nice and smooth. I haven't dont any stress testing, but it seems to run good.
We need a FPS counter in there soon, at least before we do culling. There are already font and text examples online.
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
|
« Reply #3 on: 2006/11/14 03:21:45 » |
|
I just finished getting the basic Octree structure in place, so we should be able to put together a frustum culler pretty quick with that. People want to see some new shaders first though, so I'll get a couple of those done and then work on finishing the octree/fps counter stuff.
|
|
|
|
|
Logged
|
|
|
|
|
jadams
|
|
« Reply #4 on: 2006/11/18 06:36:15 » |
|
I was just reading on scene graphs and octree. What I found indicates that octree originally was used for pixels and the like. When you get the time would you mind digressing on why/how the scene graph and octree are used together?
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
|
« Reply #5 on: 2006/11/18 09:53:32 » |
|
Scene graphs and octrees are more frequently used separately. The scene graph stores and loads level geometry and all of its needed things (like sounds and textures) whereas the octree is used at runtime to cull out unneeded draw operations. This is what my implementation does so far, although it still needs a bit more tweaking before I put it online.
|
|
|
|
|
Logged
|
|
|
|
|
jadams
|
|
« Reply #6 on: 2006/11/21 20:10:47 » |
|
One of the microsoft gurus turned me on to PIX for windows. Told me way more information than I can digest. PIX ships with DX9 SDK. It gives a bunch of stats frame by frame. Just start pix, start an experiment, point it to your compiled exe, then click hud and start. The results end of the experiement yield mroe info.
Here's what I did. I loaded a 100 x 100 grid of tiger.x. Compiled and then started an experiment with PIX. Here's the results of the first few frames (unknown details omitted:
FPS
1.5
30.1
14.3
20.6
20
32.1
(hangs right around 30 for the rest of the test)
Locks on VB objects this frame
8
0
0
0
0
0
Locks on IB objects this frame
8
0
0
0
0
0
Locks on texture objects this frame
16
0
0
0
0
0
SetPixelShader calls this frame,SetTexture calls this frame, SetVertexShader calls this frame
632 632 632
632 632 632
632 632 632
632 632 632
632 632 632
632 632 632
Its odd that 632 showed up. I was expecting 625. There must be some extra calls in there I don't see in the code. No matter, if I did my math right, that's around 300k polys @ ~ 30 fps.? :oThat's on a real crappy video card and pretty low spec machine too. Not bad.
I do have a question though, should we see every mesh get a draw call, even if its not in the viewport?
|
|
|
|
|
Logged
|
|
|
|
|
Chr0n1x
|
|
« Reply #7 on: 2006/11/21 20:31:56 » |
|
Yeah you should, without any culling on, every mesh should get the call, whether its drawn to the screen or not.
Nice stats though, thanks for the details.
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
|
« Reply #8 on: 2006/11/22 01:39:14 » |
|
The meshes outside the viewport will be culled out by the octree implementation later on in development when that part of the project is finished
|
|
|
|
|
Logged
|
|
|
|
|
jadams
|
|
« Reply #9 on: 2006/11/25 14:06:28 » |
|
That's kind of silly. You'd think the render calls would automatically be ignored if the object is not visible in the frustum. It makes no sense at all to automatically render them. Just a rant  |
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
|
« Reply #10 on: 2006/11/25 23:35:44 » |
|
You'll have to rant to the API writers about that one, or the video card manufacturers, cause they made it so |
|
|
|
|
Logged
|
|
|
|
|
jadams
|
|
« Reply #11 on: 2006/11/26 09:49:57 » |
|
Yea, I know its not your doing. It just makes no sense |
|
|
|
|
Logged
|
|
|
|
|
Chr0n1x
|
|
« Reply #12 on: 2006/11/26 21:26:50 » |
|
Either way they would have to figure out what is in and what is outside the frustum, so in the end its the same, just having them do it means less work for us.
|
|
|
|
|
Logged
|
|
|
|
|
Tiago
|
|
« Reply #13 on: 2007/03/09 11:55:12 » |
|
i think i can come up with a reason why it doesnt cull like that. say you have a shader that makes an object behave somehow (ej: reflect) based on another object, now, if your camera is between both objects then it would cull the draw of the one behind you leaving the other object without vertex/pixel data to do his thing.
i might be all wrong about a bunch of stuff there but it kind of makes sence to me
|
|
|
|
|
Logged
|
|
|
|
|
