Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Chris_F

Member Since 04 Oct 2010
Offline Last Active Yesterday, 11:07 PM

#5145396 where to start Physical based shading ?

Posted by Chris_F on 08 April 2014 - 10:03 AM

http://seblagarde.wordpress.com/2011/08/17/hello-world/

http://seblagarde.wordpress.com/2011/08/17/feeding-a-physical-based-lighting-mode/

http://blog.selfshadow.com/publications/s2013-shading-course/

http://www.gamedev.net/topic/639226-your-preferred-or-desired-brdf/




#5144698 OpenGL using data outside texture coordinates range when enabling filtering

Posted by Chris_F on 06 April 2014 - 05:44 AM


Is there an easy solution for this that doesn't involve hacking?

 

Absolutely. Use an array texture. They've been available since OpenGL 3.0.




#5143794 \why can't I initialize a multidimensional C array with zeroes

Posted by Chris_F on 01 April 2014 - 05:23 PM


This compiles but it in terms of correctness, “int multArr[3][2] = {{0}};” is better.

 

What's better about it? Correct code is correct code, and the first example is shorter while being very concise about its intent.

int multArr[3][2] = {0}; for C
 
int multArr[3][2] = {}; for C++



#5143324 Relying on thread_local variables bad?

Posted by Chris_F on 30 March 2014 - 05:17 PM

 


You can make use of common extensions refereed to as Direct State Access to avoid most of this bind-to-edit behavior. For example, instead of glBufferData you can use glNamedBufferDataEXT.

 

Not in practice. Not all drivers support DSA.  Relying on GL extensions or even new versions is risky business.

 

 

Nvidia and AMD have both supported these for a very long time. If need be you could even implement your own versions as fallbacks as is described here:

 

http://www.gdcvault.com/play/1017850/

http://adrienb.fr/blog/wp-content/uploads/2013/04/PortingSourceToLinux.pdf




#5143197 Opengl standard libraries

Posted by Chris_F on 29 March 2014 - 11:26 PM

I am just learning opengl but I thought freeglut was also a library? What is glew, gl, glu I thought these were all libraries as well? And I don't know what these are for.  

 

GLUT is a library which mostly handles window/context creation and user input. Some alternatives are GLFW and SDL.

 

GLEW is one of many libraries which loads OpenGL function pointers, saving you from having to do it yourself manually.

 

GLU is a high level utility library which is deprecated. A lot of its matrix creation functions can be replaced with equivalent functions from GLM, which is a math library which tries to mimic the GLSL vec/matrix types.




#5143188 Relying on thread_local variables bad?

Posted by Chris_F on 29 March 2014 - 09:48 PM


First, usually OpenGL code looks a bit like this:

glBindBuffer(bufferId);
glBufferData(pointerToData);

glBindBuffer(anotherBufferId);
glBufferData(pointerToMoreData);

glBindBuffer(bufferId);
glDrawElements(/* element type, count and such here */); // Drawing using the last bound object

 

You can make use of common extensions refereed to as Direct State Access to avoid most of this bind-to-edit behavior. For example, instead of glBufferData you can use glNamedBufferDataEXT.




#5143023 How to time bomb a beta?

Posted by Chris_F on 29 March 2014 - 02:15 AM


rootkit and install something in the MBR

 

That's a good way to ensure nobody ever plays any of your games ever again. wink.png




#5141879 Help with Smooth Gradient on Skydome

Posted by Chris_F on 24 March 2014 - 09:09 PM


Display quality aside, this is a general problem that can appear because in some situations 8 bit per channel still is not enough

 

8-bit is really never enough (not if you are generating images at 8-bits, anyway) unless you are doing something like a 0 to 255 gradient that is 256 pixels wide. Dithering down from 16-bits+ to 8-bits is absolutely necessary to get gradients without banding. A more complex skydome texture would hide banding a little better.




#5141860 mingw

Posted by Chris_F on 24 March 2014 - 07:21 PM

It's a port of the GCC compiler to the Windows platform. Unlike the GCC you would find on Linux, MinGW comes with Windows specific headers and produces executables with the PE format instead of ELF. It's free and open source and can be seen as an alternative to Microsoft's Visual C compiler or Intel's ICC. MinGW-w64 is an alternative version that supports 64-bit executable.

 

Here are some links to easy to install distributions of MinGW/MinGW-w64 if you want to give it a try.

 

http://tdm-gcc.tdragon.net/

http://nuwen.net/mingw.html

 

 




#5140741 Array of samplers vs. texture array

Posted by Chris_F on 20 March 2014 - 01:14 PM

 

 

A texture array is a native resource type designed to let you access pixels in a big 3d volume of mip-mapped 2d slices.

 

An array of samplers is syntactic sugar over declaring a large number of individual samplers.

It's the same as having sampler0, sampler1, sampler2, etc... If you're using them in a loop that the compiler can unroll, then they're fine. If you're randomly indexing into the array, then I'd expect waterfalling to occur (i.e. if(i==0) use sampler0 elif(i==1) use sampler1, etc...)

 

I'm sure on old hardware that is the case. Old hardware doesn't even support bindless textures, so that is not really an issue anyway.

 

A quick experiment that renders 1024 random sprites per frame from an array of 32 images shows a performance difference of about 0.05ms when comparing a TEXTURE_2D_ARRAY to an array of bindless handles stored in a SSBO.

 

Edit: I just changed the SSBO to a UBO and now there is no performance difference at all.

 

That's really cool. What kind of GPU are you using?

I'd be interested to see what your shader code looks like... You've got an array of samplers inside a UBO, and then you just index that array when fetching texture samples?

 

I wonder if these performance characteristics are reliable for all vendors that support the necessary extensions... Which vendors do support bindless; is it just nVidia?

 

 

basically

layout(binding = 0, std430) readonly buffer texture_buffer
{
    sampler2D textures[];
};
 
in vec2 tex_coord;
flat in int id;
out vec4 frag_color;

void main()
{
    frag_color = texture(textures[id], tex_coord);
}
GLuint textures[32] = { 0 };
GLuint64 texture_handles[32] = { 0 };
glGenTextures(32, textures);

for (int i = 0; i < 32; ++i) {
    GLuint texture = textures[i];
    glTextureStorage2DEXT(texture, GL_TEXTURE_2D, 8, GL_SRGB8_ALPHA8, 128, 128);
    glTextureSubImage2DEXT(texture, GL_TEXTURE_2D, 0, 0, 0, 128, 128, GL_RGBA, GL_UNSIGNED_BYTE, image_buffer + i * 65536);
    glGenerateTextureMipmapEXT(texture, GL_TEXTURE_2D);
    glTextureParameteriEXT(texture, GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
    glTextureParameteriEXT(texture, GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
    glTextureParameteriEXT(texture, GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glTextureParameteriEXT(texture, GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
    GLuint64 handle = glGetTextureHandleARB(texture);
    glMakeTextureHandleResidentARB(handle);
    texture_handles[i] = handle;
}
 
glNamedBufferStorageEXT(buffer, sizeof(texture_handles), texture_handles, 0);
glBindBufferBase(GL_SHADER_STORAGE_BUFFER, 0, buffer);

Tested this on a GTX 760 which is based on the GK104 version of Kepler. To my knowledge Kepler is the only thing which currently supports bindless textures, but AMD and Intel could have it soon enough. It probably will never be available on older GPUs, as it is really more of an OpenGL 5 hardware feature.




#5140413 Unreal Engine 4

Posted by Chris_F on 19 March 2014 - 02:26 PM

 


This news will hurts Unity a lot

 

I don't think it will hurt Unity, not by a lot anyway. Of course this is exiting for everyone even remotely interested in game development, and I can't wait for the "how do I do this in C++ with the unreal engine" that are likely to arise.

 

The reason why I don't think this will hurt Unity is simply because of the complexity involved in getting something to work in the unreal engine in contrast to Unity, just the fact that the unreal engine lets you use C++ makes the unreal engine "harder to use" as it will involve more to take into consideration. With unity, you can have a working game in just a few lines of code (so to speak).

 

I think this is more likely to cause a shift where the more serious people/studios that want to do some more advanced stuff with their game will end up having a favor towards the unreal engine whereas people/studios with little experience/expertise or just for small games will still benefit (or also prefer) unity. Or at least, I hope people understand how to use the right tools for the right job ;)

 

I'm curious to see where this is headed though! smile.png

 

 

I don't think that is really the case. The c++ source is just an added benefit. You can work with UE4 without touching any c++, as it has a noob friendly visual scripting system. By contrast, Unity requires C# or JavaScript knowledge. Also, Unity Pro costs $1500 or $75/mo (the free version lacks basic features) and with UE4 you get the whole shabang for $19/mo, which makes UE4 the clear winner in my eyes.




#5140371 Array of samplers vs. texture array

Posted by Chris_F on 19 March 2014 - 12:08 PM

A texture array is a native resource type designed to let you access pixels in a big 3d volume of mip-mapped 2d slices.

 

An array of samplers is syntactic sugar over declaring a large number of individual samplers.

It's the same as having sampler0, sampler1, sampler2, etc... If you're using them in a loop that the compiler can unroll, then they're fine. If you're randomly indexing into the array, then I'd expect waterfalling to occur (i.e. if(i==0) use sampler0 elif(i==1) use sampler1, etc...)

 

I'm sure on old hardware that is the case. Old hardware doesn't even support bindless textures, so that is not really an issue anyway.

 

A quick experiment that renders 1024 random sprites per frame from an array of 32 images shows a performance difference of about 0.05ms when comparing a TEXTURE_2D_ARRAY to an array of bindless handles stored in a SSBO.

 

Edit: I just changed the SSBO to a UBO and now there is no performance difference at all.




#5139762 [TEXTURE] BC7

Posted by Chris_F on 17 March 2014 - 12:26 PM


Using BC5 you have to compute the vector from the normal map like that for each pixel

 

A fairly trivial calculation by today's standard. The advantage is that the R and G channels are completely uncorrelated, and you have 8bpp divided between just two channels instead of 3. If anyone happens to know of a in depth comparison of BC5 and BC7 specifically for normal maps, I'd be interested to see it.

 


Does that mean BC7 can't be used because of that or it's a particular case where BC7 should not be used ?

 

I would say to use BC1 over BC7 whenever you can get away with it, e.g. whenever the quality difference will not be noticeable.




#5139597 [TEXTURE] BC7

Posted by Chris_F on 16 March 2014 - 08:54 PM

BC7 isn't really a he so much as it is a inanimate and gender neutral it. BC7 can't represent HDR, so for that you will want BC6H. BC7 isn't ideal for normal maps, so for that you will want BC5. If you have multiple uncorrelated single channel textures combining them in a BC7 texture would introduce cross talk, so for that you will want BC4. Not all textures need the highest quality possible. For some textures BC7 will be too large, so for that you will want BC1.

 

No one format is good at everything, that is until ASTC is implemented on desktop GPUs, then you will be able to replace all of those formats with one.




#5138277 Having a VBO/VAO for each object.

Posted by Chris_F on 11 March 2014 - 07:46 PM


Isn't a shader storage buffer object considerably slower than an uniform buffer object?

 

When I'm only rendering a few thousand sprites to the screen, there is no noticeable difference in speed. Using a UBO though puts a relatively small limit on the number of sprites, since I think even newer GPUs are limited to around 64K.






PARTNERS