Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 41
» Latest member: Joachim
» Forum threads: 151
» Forum posts: 485

Full Statistics

Online Users
There are currently 13 online users.
» 1 Member(s) | 12 Guest(s)
GSalvato

Latest Threads
Cube OpenGL ES 2.0 exampl...
Forum: Getting Started
Last Post: GSalvato
39 minutes ago
» Replies: 1
» Views: 13
Chapter 7 Assets
Forum: Fundamentals Errata/Questions
Last Post: Brian Beuken
Yesterday, 08:28 PM
» Replies: 16
» Views: 217
OpenGLES3.0 causes flcker...
Forum: Help my code won't work??
Last Post: Brian Beuken
Yesterday, 06:22 PM
» Replies: 3
» Views: 21
Asus Tinkerboard
Forum: Other SBC's
Last Post: Brian Beuken
02-17-2019, 02:27 PM
» Replies: 9
» Views: 1,076
Make sure you update and ...
Forum: Getting started
Last Post: jomoengineer
02-15-2019, 08:02 AM
» Replies: 1
» Views: 50
So....what do I do?
Forum: Getting started
Last Post: Brian Beuken
02-13-2019, 09:10 AM
» Replies: 10
» Views: 2,236
Reviewing the code
Forum: Scratchpad Games
Last Post: Brian Beuken
02-13-2019, 12:53 AM
» Replies: 1
» Views: 75
If your trial has run out...
Forum: Getting started
Last Post: Brian Beuken
02-11-2019, 10:08 PM
» Replies: 1
» Views: 39
Finally have a machine
Forum: OpenGLES3.2 Shaders
Last Post: Brian Beuken
02-11-2019, 11:51 AM
» Replies: 6
» Views: 843
Rock Pi 4
Forum: Other SBC's
Last Post: Brian Beuken
02-10-2019, 02:32 PM
» Replies: 4
» Views: 356

 
  Cube OpenGL ES 2.0 example
Posted by: jomoengineer - 7 hours ago - Forum: Getting Started - Replies (1)

There is a an example and instructions on how to run OpenGL ES 2.0 with QT
https://doc.qt.io/qt-5/qtopengl-cube-exa...ngl-es-2-0

Print this item

  OpenGLES3.0 causes flckering
Posted by: Brian Beuken - Yesterday, 12:27 AM - Forum: Help my code won't work?? - Replies (3)

This is more for my reference than anything in the book but if you are using an OpenGLES3.0+ system you will get significant flicker on your models.

Its being caused by an issue with the Depth Functions,  I don't know exactly why at the moment, but I have worked out if you disable dept_test you stop flickering...sadly you also get messed up culling on your poly's but at least step one in the bug hunt is reached.

Now...why are OpenGLES3.0 depth buffers different from OpenGLES2.0...thats step 2. I'll let you know.

Print this item

  Make sure you update and have Linux Development in place
Posted by: Brian Beuken - 02-14-2019, 03:24 PM - Forum: Getting started - Replies (1)

a few of my students have been working with Linux dev options and that has thrown up a couple of gotacha moments.

1st you need to make sure your visual studio 2017 is updated to the latest version, it needs it, or it has issues working out the remote access.
2nd you have to have Linux devdlopment with C++ installed 

both the update and Linux dev options can be checked at Tools->Get Tools and Features.

Even though you may get options to create new linux project. or it may load one of my dual config demos, you will have issues if you have not updated and installed the features.

Print this item

  Reviewing the code
Posted by: Brian Beuken - 02-11-2019, 01:11 AM - Forum: Scratchpad Games - Replies (1)

Hey all, a reader has pointed out there is quite a lot of missing files from chapter 6 on, sorry I thought that the book made it clear you are building on the code you produce, but I accept that might not be as clear as I intended, and indeed some small demo files I reference are not on the download site, so I am going to start adding staged builds for chapter 6 onward to help you, though I still want you to try to build on the code base as you go.

I'll get this in place over the next few weeks

Print this item

  If your trial has run out, try Dual Build Space Cadet
Posted by: Brian Beuken - 02-11-2019, 01:06 AM - Forum: Getting started - Replies (1)

The Download page now has a dual config version of Space Cadet, both VisualGDB and VisualStudio for Linux
Be sure to add a connection to your SBC, in the Tools->Cross Platform->Connection manager, and change all the current targets to yours. And build as an ARM config

At the moment the build is Raspberry Only, but its not a massive leap to make it generic to all Linux SBC's

I also note that you need to use the Linux Console window to see the code's printf output. Debugging/break points and watches, all work fine but there's a bit too much strange info you don't need, not sure how to turn that off.

If your VisualGDB Trial has run out and you don't want to buy an extension, you can continue with this Visual Studio version, its a little clunkier, and does sometimes crash your Visual Studio, but generally it works ok, and its free.

Print this item

  Dragonboard 410c
Posted by: Brian Beuken - 02-07-2019, 11:39 PM - Forum: Other SBC's - No Replies

Had this for quite some time but found it a bit hard to get going due to poor software, but thats changed, its got a bit more mature and has a decent degree of support now.  They have a decent Debian (Jessie) and Mesa Libs go on. It actually has GLMark2-es2 on board when installed, and does seem to run pretty well through the intital runs, though it never completes the cycle so gives no score. But it seems very fast. Its an OpenGLES3.0 system so it should be pretty nippy.

Of course no native drivers on board, so Mesa is doing the work and it does seem to be emulating a lot.

Test code does build but with a bit of effort, it can't run more than 1 core at a time, it freezes if you try to do 2  or more, so clearly needs a serious heatsink to get some decent performance out of it.

Anyway, demo runs, its ok, no real problems, but only at 26-30fps, which is way below what that GPU is capable of. So while I know this to be a beast, until proper drivers come out its not going to be high on my list boards to play with.

I'll keep an eye open for updates though, if it gets its GPU sorted and maybe has a better heatsink fitted it could be really nice.

Print this item

  OpenGLES3.2 features
Posted by: Brian Beuken - 02-04-2019, 01:39 PM - Forum: OpenGLES3.2 Shaders - No Replies

Now 3.0 and 3.1 gave us a lot of new stuctures and buffers to use making it really quite on a par with OpenGL itself. 
There was also an impressive Extension pack for 3.1 which was available only for Android

However those Android only features were then wrapped into OpenGLES3.2 as standard features and this has allowed OpenGLES to continue with its alightment of OpenGL by adding few very impressive extra features including two new shader types


Tessellation shaders
Geometry shaders
Now some OpenGLES3.1 boards do have Geometry and Tesselation shaders as extensions (Tinkerboard for example) but thats just because they have the Android Extension Pack. Its safer to only attempt Geometry and Tessellation on a full 3.2 board in Linux, but probably safe if you are coding in Android.


These don't in themselves give you any extra power, in fact they can be quite a cost on framerates if you over use them, but they do allow you to greatly enhance the detail of your graphics from reasonably simple basic model types. 

Tessellation shaders (they come in a pair) in particular, really need a massivly powerful GPU, but when used well can create wonderful Levels of Detail in our models, but I confess I find using them to be overcomplex and combersome, running a few tests on a very simple PC GPU card shows significant slow down, I havn't tried to build anything on an SBC, but I imagine the frame rates would plummet. But for fairly static screens, not requireing real time updates like menus you can turn simple models into things of beauty.
Here's some info on Tessellation shaders...prepare for a brain melting.. 
http://ogldev.atspace.co.uk/www/tutorial...ial30.html


Geometry shaders however used sparingly can do some really cool things, and my favourite OpenGL tutorial site has a great demo on how to use them.
https://learnopengl.com/Advanced-OpenGL/Geometry-Shader


There's also more advanced texture types, ability to work with compressed textures reducing our footprint,  new blending capabilties and mutlisampling added as well as (praise the coding gods) some debug features which really start to be needed as all these extra features can make a shader chain much more prone to bugs.

As with OpenGLES3.1 though we must be aware that we have very very feeble GPU's on an SBC, and just becuase they can do something, does not mean its wise to do it. In the same way as per pixel shading looks amazing, don't expect 60fps updates if every model uses it. Likewise Tesselation and Geometry shaders can greatly enhance the visual effect of your project with little effort on the coding side, it all takes up processing cycles and can slow things down.

But we dont' care do we Big Grin
Even though its been out a couple of years now, there really are not many devices using it yet, Only high end phones and tablets, but developers are are still mostly targetting 2.0 and 3.0 as base level systems due to teh market share they present.

So with only a few devices, there's not a lot of demo's out there to show the real power of the new shaders... I llike to refer to the ARM developer site for tutorials and explinations, well more explinations than tutorials.

However do remember what I said about OpenGLES3.2 being more complient with OpenGL, if you check out some OpenGL4.0+ demos you'll certainly get some ideas of how to use GLES3.2 in anger.

https://developer.arm.com/docs/100587/la...engl-es-32

Print this item

  Nice features of GLES3.1
Posted by: Brian Beuken - 02-04-2019, 12:13 PM - Forum: OpenGLES3.1 Shaders - Replies (1)

There are a number of small tweaks to 3.0, but overall its not a massive leap in the same way 3.0 was over 2.0.
But there is something that is wonderful to play with and can really give us quite a boost.

Compute Shaders

Compute shaders basically let us pass over some of our more complex graphic tasks to the GPU to handle. Its not quite the same as multi core coding on CPU, since the CPU itself can't actually get hold of any of the info the compute shader produces (well yes it can, kinda, but only by grabbing buffers which is slooowww), but it is essentially letting us use redundant computing power in our GPU to release some work from our CPU instructing our GPU to do things.

The compute shader is best used for repetitive graphical processes that don't need to be interrupted, and can run in the background creating different buffers or textures that your normal draw called shaders can make use of. While you are busy setting up your models, doing your physics, working out what AI is going to do, the GPU is idle, so we can make it work on creating buffers for things like shadows or lighting systems or even ambient colours to indicate passage of night and day. that can be stored in a GPU buffer ready for your shaders to work with when you are ready to execute a draw call.

A short intro here.

https://community.arm.com/graphics/b/blo...te-shaders

Now sadly it has to be said, SBC GPU's are not great for this kind of work, they are often massivley overloaded just trying to render so don't have a huge capacity to run compute shaders as well, but as with all things SBC, a little used wisely can go a long way.

Print this item

  A useful site
Posted by: Brian Beuken - 02-04-2019, 11:22 AM - Forum: OpenGLES3.0 Shaders - No Replies

Here's some excellent simple tips on changing your work flow from OpenGLES2.0 to OpenGLES3.0

http://www.shaderific.com/blog/2014/3/13...engl-es-30

The key thing to consider is that there's not a huge amount changes on the client (main code) side, the bulk of the changes happen in the shader language itself.
There's a few new features you might want to send values to but its still a case of the client sending attributes, now called in values,  and uniforms and letting the shaders to their work.


That said there are rather a lot of nice things in OpenGLES3.0, heres a list I found on stackoverflow. Most of these relate to new data structures you can use, or extensions to exisiting structures, making your shaders far more flexible.  Most normal mortals won't use but a fraction of these new features but you may discover that something you are trying to do, but failed or found too slow, is now much more plausible.  
For me the biggest thing is VAO's and Instancing and multiple render targets. These make it very easy to populate and dress a scene with large numbers of the same model, with or without manipulation, as well as a far easier way to create shadow buffers and light effects.


  • OpenGL Shading Language ES 3.00

  • transform feedback 1 and 2 (with restrictions)

  • uniform buffer objects including block arrays

  • vertex array objects

  • sampler objects

  • sync objects and fences

  • pixel buffer objects

  • buffer subrange mapping

  • buffer object to buffer object copies 314

  • boolean occlusion queries, including conservative mode

  • instanced rendering, via shader variable and/or vertex attribute divisor

  • multiple render targets

  • 2D array and 3D textures

  • simplified texture storage specification

  • R and RG textures

  • texture swizzles

  • seamless cube maps

  • non-power-of-two textures with full wrap mode support and mipmapping

  • texture LOD clamps and mipmap level base offset and max clamp

  • at least 32 textures, at least 16 each for fragment and vertex shaders

  • 16-bit (with filtering) and 32-bit (without filtering) floating-point textures

  • 32-bit, 16-bit, and 8-bit signed and unsigned integer renderbuffers, textures, and vertex attributes

  • 8-bit sRGB textures and framebuffers (without mixed RGB/sRGB rendering)

  • 11/11/10 floating-point RGB textures

  • shared exponent RGB 9/9/9/5 textures

  • 10/10/10/2 unsigned normalized and unnormalized integer textures

  • 10/10/10/2 signed and unsigned normalized vertex attributes

  • 16-bit floating-point vertex attributes

  • 8-bit-per-component signed normalized textures

  • ETC2/EAC texture compression formats

  • sized internal texture formats with minimum precision guarantees

  • multisample renderbuffers

  • 8-bit unsigned normalized renderbuffers

  • depth textures and shadow comparison

  • 24-bit depth renderbuffers and textures

  • 24/8 depth/stencil renderbuffers and textures

  • 32-bit depth and 32F/8 depth/stencil renderbuffers and textures

  • stretch blits (with restrictions)

  • framebuffer invalidation hints

  • primitive restart with fixed index

  • unsigned integer element indices with at least 24 usable bits

  • draw command allowing specification of range of accessed elements

  • ability to attach any mipmap level to a framebuffer object

  • minimum/maximum blend equations

  • program binaries, including querying binaries from linked GLSL programs

  • mandatory online compiler

  • non-square and transposable uniform matrices

  • additional pixel store state

  • indexed extension string queries

Print this item

  Chapter 7 Assets
Posted by: GSalvato - 01-31-2019, 05:25 PM - Forum: Fundamentals Errata/Questions - Replies (16)

Hi Brian,
sorry to bother you again... Are the assets of chapter 7 available for download ?

Ciao,
Gabriele

Print this item