Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Ubik

Member Since 07 Nov 2002
Offline Last Active Yesterday, 12:28 PM

#5221347 Vertices and indices in the same buffer?

Posted by Ubik on 04 April 2015 - 10:45 AM

I'm thinking of having a single Buffer concept against having a concept for each of VertexBuffer, IndexBuffer and so on, mainly from the perspective of type safety (i.e. type "Buffer" vs types "VertexBuffer", "IndexBuffer" and so on). Both OpenGL and Direct3D tell that it is possible to mix different kinds of data in the same buffer, but also say that it might come with a performance penalty.

OpenGL's vertex buffer object extension text says:
 

Note that it is expected that implementations may have different
memory type requirements for efficient storage of indices and
vertices.  For example, some systems may prefer indices in AGP
memory and vertices in video memory, or vice versa; or, on
systems where DMA of index data is not supported, index data must
be stored in (cacheable) system memory for acceptable
performance.  As a result, applications are strongly urged to
put their models' vertex and index data in separate buffers, to
assist drivers in choosing the most efficient locations.

But that is very old text, apparently from 2003, so it might be completely outdated. So I looked into what D3D documentation says. Here's what D3D11_BIND_FLAG's Remarks section tells:
 

In general, binding flags can be combined using a logical OR (except the constant-buffer flag); however, you should use a single flag to allow the device to optimize the resource usage.

D3D11 is from 2008, so it's documentation may be not very relevant anymore in this regard too. I don't know what would be good specific terms to find this out, and don't really have too good chances of just testing on a multitude of platforms, so am asking from you now.

I guess I could ask this in two ways:

1) Is it (more often than not) a bad idea to make heterogeneous buffers (I have no idea if there is an official term for this) today?
2) Is it (more often than not) a good idea to make heterogeneous buffers today?

For more specific context, I'm personally interested in how things are in current hardware (and drivers) in the PC, not mobile nor console world, but also the not so recent HW interests me. (Though I have access to one not exactly new GPU myself when I just boot up my own 'puter, to personally test things out...) My API of choice is OpenGL. But let's not restrict this only to my circumstances, it would be interesting to know how things are in general.




#5187881 Indexed Drawing - Is it always useless when every face should have its own no...

Posted by Ubik on 18 October 2014 - 03:05 PM

Models done in a "polygonal style" may very well have lots of faces that have more than three corners. It's easy to imagine spaceship or station models having lots of four-sided faces and it's not a big stretch to come up with designs with more complex flat surfaces. Still, if the models are simple and few enough, it really might not matter much at all.




#5059468 Loading PHP file into DIV via AJAX

Posted by Ubik on 05 May 2013 - 08:17 AM

Without having tested the code, Navall's solution looks otherwise good to me, but has a piece missing - you will have to re-setup the click handlers within a callback passed to load, because as the content of #result gets replaced, the new content will have no handlers set for any elements. This gets easily messy, because essentially you have to setup the click handler doing a load() within the callback of the said load().
 
However, there's an easier way: jQuery's on() allows you to attach the handler to the container element* with an additional selector that limits the handler to specific elements within the container:
 
// "#result a" has just been split into "#result" and "a"
$('#result').on('click', 'a', function() {
    $('#result').load($(this).attr('href'));
    return false;
});

 

* I'm assuming the element #result doesn't get replaced by DOM manipulation or load() or other change, as the idea is to attach the handler to a static element. It's good idea always to attach the handler to the innermost unchanging element, for example to #result in this case.




PARTNERS