Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Jul 2012
Offline Last Active Private

#5117510 Mesh Physics bullet physics and assimp

Posted by on 17 December 2013 - 01:59 AM

Might be easier to use btTriangleIndexVertexArray::addIndexedMesh, http://bulletphysics.org/Bullet/BulletFull/classbtTriangleIndexVertexArray.html#a106dc4486bccc8b6a3e2c250ad7e238c


You'll want to make copies of the assimp data (just memcpy into suitably sized arrays) then feed it to bullet.

You'll also need to keep track of those pointers as bullet does not take ownership of anything it did not

allocate itself.

#5114753 Vertex Array Object + Direct State Access

Posted by on 05 December 2013 - 08:37 PM

To go one wiki page further, under glVertexAttribPointer: "GL_INVALID_OPERATION​ is generated if no vertex array object is bound."


The following thread is also relevant, but nobody explicitly says anything like "yes, I've fallen back to older GLSL and non-generic attributes":


#5042211 Starting OpenGL

Posted by on 12 March 2013 - 12:11 AM

Check that gdi32.lib is being linked.

#5036273 Best way to load a 3D object into memory from a file?

Posted by on 25 February 2013 - 01:33 AM


Assimp supports importing a wide array of file formats.

Best way to use it is to import using assimp and export to your own format.

#5031311 glGenTextures

Posted by on 11 February 2013 - 09:27 PM

It works the same way as glGenTextures, just pass 1 and a pointer to the ID.


Edit: Although based on the code above, perhaps just glTexSubImage2D or glTexImage2D would be better (or even faster) than creating an entirely new texture every frame?

#5025649 Making a Static Lib in Linux

Posted by on 25 January 2013 - 09:04 PM

The S option is likely giving you assembly text output. Use -c instead.

#5024416 OpenGL triangle example

Posted by on 22 January 2013 - 02:20 PM

There's missing () after glGetError. As is it's not getting called (what you have there is a comparison of the function's address).

#5019503 Practical rendering approach of an object

Posted by on 09 January 2013 - 10:23 AM

1. Can't really avoid putting the matrices in constant buffers. For something like world transform that is not necessarily constant frame-to-frame, more than one rotated constant buffer dedicated to the world transform would be necessary to avoid sync issues (unless you depend on drivers to do orphaning, which is far from gauranteed). It might be worth it though to simply modify a single 'matrices' constant buffer each frame for each object, and only do something more complex if you actually need to.


2. Which is essentially how tons of one object with one draw call (instancing) works.


3. Probably not worth the trouble unless you have a ton of unique non-moving objects and that single matrix multiplication in the shader is slowing things down (unlikely).

#5017503 I need help understanding ARB_instanced_arrays.

Posted by on 04 January 2013 - 03:12 PM

The VBO is just a normal VBO. It just contains matrices. The glVertexAttribPointers setup the attribute for the shader. More than one are needed because GLSL implements matrix attributes as 4 vec4s with consecutive positions/IDs; the stride is a full 4x4 matrix. The glVertexAttribDivisor =1 tells GL that that attribute is per each instance draw (rather than per vertex =0).


After setting all that up, assuming your shader is set up to use the attribute for the world transform instead of a uniform, then you just call glDrawElementsInstanced which takes the number of instances as the last parameter that matches the number of matrices in your VBO.

#5017304 Passing attributes to shaders

Posted by on 03 January 2013 - 05:40 PM

Check that your program object is linking properly.

#5015538 Miscellaneous OpenGL questions (mostly dealing with shaders)

Posted by on 29 December 2012 - 03:20 PM

I couldn't disagree more. However, everything depends on what "results you're looking for". That custom shader that outputs the values does just that and often only that. Then the shaders that do lighting are completely separate. Now you have much fewer shaders as well as many more lights. Clever implementations even get more dynamic shadowing (I haven't looked at those much though).


I'd have to disagree that deferred shading is any harder than forward, especially if you've done something like shadow mapping before (ie, you've done more with OpenGL than send a single tri through a VAO). I thought you summarized deferred (in the manner that most would implement) rather succinctly, and of course more research would be needed to implement it.


The lighting shader(s) for deferred are a lot less complicated than the uber-shader or 293485 shaders for various combinations of diffuse texturing (splatting, bump, etc), shadow or not, number of lights on object, etc. Perhaps not just one, but not a "super-shader" when it has a single, easily maintainable task to perform per shader. Separable shader objects help, but I really prefer the clean split.


You'd have to be more controlled in the way you render your scene, with the different render targets and the way you pack/unpack information, etc. In one word, you'd have to be an obsessive with your rendering pipeline.


Curious, filling a few buffers with carefully chosen layouts is hardly obsessive (I apologize for the censorship, but it wasn't relevent to what I was quoting, so I just left it out). In what way to you need to be more controlled? I get needing a forward pass for transparency, but chances are there's not that much of that and you didn't need that many lighting effects from it anyway (or at least I don't which is why I don't mind needing the pass for it).

#5015345 Miscellaneous OpenGL questions (mostly dealing with shaders)

Posted by on 29 December 2012 - 12:23 AM

I know you can apply shaders to models, and basic lighting can be done that way. Is there a way to use a shader to add lighting to every model in a scene at once? I'm having a very hard time specifying this question dry.png


If you use deferred shading (as described by LordJulian above), you are no longer on the level of individual meshes, as (often) all you have is the relevent shading data for that pixel. A common technique is to draw bounding geometry for calculating dynamic lighting so that lighting is only calculated if the light is visible and touching (or close to touching) those pixels. Deferred shading can also be useful to reduce the number and complexity of shaders due to its separation of calculating diffuse color from pretty much all of the lighting options.

#5014606 What kind of optimization makes C++ faster than C#?

Posted by on 26 December 2012 - 11:21 PM

C++ operates at a lower level of abstraction than C#. In C++, you could (if you wanted to) trivially fill an array with machine code, cast it to a function and run that code (it would no longer have any amount of portability at that point).

C# compiles to a bytecode that wasn't the machine code of any processor (I say 'wasn't' because I haven't followed C# in a while; they may have built one since). C# programs are run by what is often called an interpreter even though C# runtime has always compiled to machine code on the fly. In a C++ program, the progammer has manual access to freeing memory (as well as the pointers to/within it). A C# program uses the garbage collector to take care of freeing memory (as in, C# doesn't have a 'delete' operator, just 'new').


Some people might even argue that C# could be faster because C# gets compiled on the fly, the runtime knows exactly what the best actual machine instructions are for the users exact hardware (as opposed to a C++ compiler having to target some lower denominator of CPU like no-SSE, unless you actually provide multiple binaries for users to choose from or users compile themselves).


The fact that a C++ process will never slow down, use an extra thread (or *gasp* pause) for a garbage collection is probably one of the best reasons for people who like control. I thought was going to come up with better arguments, but other than memory access and allocation, it's late and I'm drawing a blank. The runtime compiling C# bytecode on the fly takes time too, and I imagine there's a threshold of how many interprets of the function before it decides to compile.

#5012866 [GL3] VAO and VBO question about dynamic/stream buffers

Posted by on 20 December 2012 - 12:21 PM

This page should have all the information: http://www.opengl.org/wiki/Buffer_Object_Streaming
There's no way around a glBindBuffer though.

#5010089 opengl 3/GLM matrix help

Posted by on 13 December 2012 - 12:56 AM

Check your ordering of multiplying the matrices together. The destination space of the combined matrix needs to be on the left of the multiply.
(both the multiplies in the first two lines of updateMatrices are backwards)

If you haven't already, do yourself a huge favor and read arcsynthesis.org/gltut all the way through. He explains all the math from the beginning and uses GLM for all the examples.