Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Tocs

Member Since 22 Apr 2005
Offline Last Active Nov 10 2014 02:16 PM

#5163081 Creating an OpenGL context on Windows with Glew.

Posted by Tocs on 26 June 2014 - 02:19 PM

I noticed 3221692565 is 0xC0072095. According to the NVidia create context spec 0x2095 is ERROR_INVALID_VERSION_ARB. So I bumped the version down to 3.3 and it successfully creates a context. Which raises more questions because I should be able to create a 4.2 context. I need a 4.2 context because of shader_storage_buffers and other things.

 

TXFvMiR.png

 

cQfKgGK.png




#5133047 Baking a Local Thickness Map

Posted by Tocs on 20 February 2014 - 03:16 PM

I know this topic is 14 days old but I started working on the subsurface scattering that uses these maps and needed a way to generate them. I found XNormalhas a built in option for this type of map. It's called "Translucency" and not "Local Thickness". You won't need to flip your normals and such. It also has a C++ library if you want to integrate baking into some sort of tool you're building, and it's free. 

 

Edit: Didn't read carefully enough XNormal was already suggested.

 

Edit: Here's the translucency map generated from XNormal used in the shader...

SiSiDHI.png




#5127220 Uniform arrays?

Posted by Tocs on 29 January 2014 - 10:01 AM

Sounds like you're maybe talking about Instancing?

 

glDrawElementsInstanced() will draw the same model several times. In order to position things differently you need to do one of a two things. 

 

A) Pass each transform and model specific data in via a Uniform Buffer Object

 

B) Pass each transform and model specific data in via a VBO with a vertex attribute divisor

 

You can draw many models (All the same) with a single draw call at different transformations and such.




#5122927 Shader works on laptop, hangs on desktop.

Posted by Tocs on 11 January 2014 - 04:31 PM

Well the loops aren't entirely slow. They're broken up by 32x32 tile. So spatially pixels in the same area are using the same list of lights. So it has the potential for the same warp/wavefront (I think those are the words NV/AMD respectively) to be using the same list. 

 

http://www.cse.chalmers.se/~olaolss/papers/tiled_shading_preprint.pdf

 

Though when I looked up the undefined-ness of texture sampling. You were correct. However, there are some texture samplings that are ok, mainly ones that don't rely on the computation of mip-maps or filtering. Because I'm using texelFetch() it should be defined... I think. (http://www.opengl.org/wiki/Sampler_(GLSL)#Non-uniform_flow_control)

 

Which points out in the sampling of shadow maps is non-uniform and I'm relying on the filtering. Perhaps it's the cause of the issue, though I'm not really sure how to fix it.

 

Thank's for your input.

 

EDIT: Missed the new post by Kaptein.

 

My shader loader checks for compile errors on every shader. And link errors on every program. If anything comes up it prints the result and asserts(false); So I can see the error. It's compiling. I just didn't include the vertex shader as it didn't seem related and there was already an enormous bit of code to look through. The vertex shader also isn't doing anything interesting.




#5078910 Managing resources

Posted by Tocs on 19 July 2013 - 07:12 AM

I ended up writing my own smart pointer for resources. 
 
 
I'm only mildly happy with it. There might be errors in my reference counting shenanigans but I haven't noticed a memory issue yet, though I haven't put it through the wringer yet. And there's probably some C++ sloppyness in there but hopefully the idea gets across.
 
It functions like a shared_ptr<> because it reference counts. But it lets you handle the storage of the asset. So if you wanted to unload assets until they're used again you could do that on the back end without uses of Asset<> ever knowing. Since its a template, it duck types a LoadFromFile () static function on the type you pass to handle loading. Eventually I want to add in things like loading on another thread and using a dummy asset until its complete. And automatic reloading of modified files. It can all be done behind the scenes.
 
I have classes like "Texture2D", "Mesh", "Shader" and these all provide a LoadFromFile (). I simply call Asset<Texture2D>::Load("Somefile.png");
 
I have a special function if I have to use a generated asset.(Such as a procedurally generated texture.) I can either give it a name and enter it into the registry of assets, or I can "wrap" it which creates an Asset<> who's job is not to delete the resource its referencing. Instead its some external object's job to delete it. This is the part I'm not entirely comfortable with, but it unifies the two methods of resource containment. (File Loaded and Generated).
 
 I can't pass extra arguments into LoadFromFile (Though this could be solved with a variardic template). There is global state here, but I suppose it wouldn't be hard to have some sort of "AssetCache<T>" instead of using global state. Also I'm using a std::map<> because I was lazy which can be slightly slow depending on how picky you are, however I don't call Asset<T>::Load() every frame. However if I have some sort of rapidly created and destroyed object that initialized itself by acquiring an asset I could hammer my std::map. Like I said I'm only mildly happy with it but I thought I'd post it in case it provided some sort of idea, also if Its a horrible idea I would love to know too.



#4947052 Patch Rendering Issue

Posted by Tocs on 07 June 2012 - 08:43 AM

It looks like your indices are attempting to access vertices that don't exist. For example Indices[591] accesses Vertices[108]. But you only have 100 total vertices.(Index out of Bounds) I've had exactly the same problem before, and have seen the geometry converge on a point like that. However you are generating your indices is where I'd think the problem is. It looks like you have forgotten to not "reach" across edges on one axis.


PARTNERS