Re: Which method is better?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Peter Venis (petervenis_at_zonnet.nl)
Date: 06/27/04 

Date: Sun, 27 Jun 2004 10:47:39 +0200

No, you described the situation incorrectly.

The scene I have is one big mesh exported from 3DsMax. The entire mesh is in
one vertex buffer, and there's only one index buffer.

Becuase I want to render only cubical chunks of the mesh (this becuase of
frustum culling) I need to devide the mesh in many parts. If I only devide
the index buffer in seperate index buffers (method one) then the indices
will reference to vertices all throughout the vertex buffer, not like you
said in 'chunks of vertices that can be referenced seperately'.

You must keep in mind that the vertices are shared vertices. If for example
I would devide the vertex buffer into seperate buffers then the total number
of vertices will increase with about 10% because many vertices need to be
duplicated.

The reason I'm hoping to keep them in one buffer is because it will take
less memory, and I won't need to go through the trouble of splitting them
into multiple buffers, much less work. But will one vertex buffer be just as
fast as seperate buffers considering the fact that I need to set a wide
range of vertices with each DrawIndexedPrimitive() call?

Peter

"Eyal Teler" <et@nospam-et3d.com> schreef in bericht
news:%235gvCO9WEHA.1144@TK2MSFTNGP10.phx.gbl...
> Okay, I'll repeat the previous question in more detail:
>
> In solution 2, say you have 4 vertex buffers, each with 100 vertices
> and corresponding index buffers. If you put all 4 buffers into one
> vertex buffer of 400 vertices, your 4 rendering calls will reference
> each chunk of vertices separately. They won't be "anywhere in the
> vertex buffer".
>
> So what's the problem with this solution?
>
> Eyal
>
> Peter Venis wrote:
> > Look at the DrawIndexedPrimitive() description in MSDN, there you will
read
> > this:
> >
> > The MinIndex and NumVertices parameters specify the range of vertex
indices
> > used for each IDirect3DDevice9::DrawIndexedPrimitive call. These are
used to
> > optimize vertex processing of indexed primitives by processing a
sequential
> > range of vertices prior to indexing into these vertices. It is invalid
for
> > any indices used during this call to reference any vertices outside of
this
> > range
> >
> > I need to call only a limited amount of indices per call, but those
indices
> > can reference to vertices anywhere in the vertex buffer, that's why some
> > calls the NumVertices parameter is almost as big as the vertex buffer
> > itself.
> >
> > Peter
> >
> >
> >
> >
> > "Eyal Teler" <et@nospam-et3d.com> schreef in bericht
> > news:uP$JO%235WEHA.2408@tk2msftngp13.phx.gbl...
> >
> >>It's not clear to me why you have to select a wide range of vertices
> >>in method 1. If you take what you have in method 2 and put it into one
> >>buffer, then you will have a limited range for each call.
> >>
> >>Eyal
> >>
> >>Peter Venis wrote:
> >>
> >>>Hi,
> >>>
> >>>I'm rendering a large group of triangles that only have a position and
> >>>normal and the same render states. Because of frustum culling, I need
to
> >>>render those vertices in different chunks by calling them through
> >
> > indices.
> >
> >>>All vertices are currently in one big vertex buffer. Which of the two
> >>>methods is better / faster?:
> >>>
> >>>METHOD ONE:
> >>>
> >>>Keep all vertices in one big buffer and only create seperate index
> >
> > buffers.
> >
> >>>This way we only need to set vertex buffer to stream 0 once and then
set
> >
> > the
> >
> >>>index buffers for each seperate call. However, each time I call
> >>>DrawIndexedPrimitive() I need to select a wide range of vertices,
> >
> > sometimes
> >
> >>>almost the entire vertex buffer.
> >>>
> >>>METHOD TWO:
> >>>
> >>>Split both the vertices and the indices into seperate buffers. This way
> >
> > we
> >
> >>>must set both the vertex and index buffer at each call but only need to
> >>>select a small range of vertices when calling DrawIndexedPrimitive()
> >>>
> >>>Peter
> >>>
> >>>
> >
> >
> >

Relevant Pages

  • Re: Large 2D Graph Additionally
    ... > with 32-bit index buffer support and lots of video memory, ... graphics card etc. if appropiate. ... on the basis that directX would take a subset of the vertex buffer ... I am much happier thinking of DirectX making graphics coding simpler. ...
    (microsoft.public.win32.programmer.directx.managed)
  • Memory Violation Copying Mesh Verticex buffer
    ... vertex buffer to a new buffer. ... I have tried various settings for cloning the mesh and for the new vertex ... Does DX not store a mesh in contiguous memory? ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: Detecting mouse click on a particular triangle
    ... Ok i posted this before reading your replies... ... > there were functions to do that with just a vertex buffer in the utilities ... >> verts make up the next triangle. ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: basic performance questions - vertices/second=>fps
    ... Especially for the vertex buffer handling and locking. ... that a smart split of the vertex buffer will have significant ... which most likely won't support vertex shader 3. ...
    (microsoft.public.win32.programmer.directx.managed)
  • Re: Detecting mouse click on a particular triangle
    ... My confusion is that these codes ... keep a second buffer around with a lockable z buffer ... there were functions to do that with just a vertex buffer in the utilities ... > verts make up the next triangle. ...
    (microsoft.public.win32.programmer.directx.graphics)