OpenGL ES2... many questions

Member
Posts: 96
Joined: 2011.07
Post: #16
(Aug 23, 2011 05:07 AM)vunterslaush Wrote:  BTW- So depth test is completely useless with transparent textures? Blink

Not really. That question hard to answer in depth just like that but it is related to your question about shaders and it is a good question.

respect,
pk

iFrog is coming.
Quote this message in a reply
Member
Posts: 25
Joined: 2011.08
Post: #17
ipeku, can you give a hint? Rasp

Mattonaise, I thought about creating a VBO for every group of consecutive (by depth order) sprites of the same texture, so I'll only have to call glDrawElements once per "texture group".
So that I'll be able to draw more than one sprite of the same texture in a single call. Maybe it's not very effective because then I'll have to create VBO's every frame... And also I'll have to calculate the vertices myself instead of using transformations.

Anyways, I'm gonna take your advice and start simple without going into all that optimization... Maybe it'll work just fine without it Smile
Quote this message in a reply
Member
Posts: 96
Joined: 2011.07
Post: #18
(Aug 24, 2011 05:24 AM)vunterslaush Wrote:  ipeku, can you give a hint? Rasp

I will try.

The thing is that the drawing order affects the outcome depending on what your doing in the shaders.

Here's an example which you can try on a paint program I'm using pixelmator but the same things are available on GIMP. Essentially you can do things like this on shaders creating your own formulas to combine colors and create effects for your game.

Here I have a semitransparent (0.5 alpha) green gradient drawn on top of a semitransparent (0.5 alpha) red gradient with alpha blending.
[Image: normal1.png]

And here the layers are drawn in the opposite order which results in a different image. Same layers, same formula but processed in a different order.
[Image: normal2.png]

However, for multiplication (source*destination) there isn't that big of a difference.
[Image: multiply1.png][Image: multiply2.png]

Now, if you have the depth buffer on, OpenGL will decide on the drawing order. Depending on what you're doing whether it's something in the shaders (multiplication or addition, etc.) or a different blending equation the outcome will be different.

With the depth buffer off you control the drawing order yourself. Hope that explains something.

respect,
pk

iFrog is coming.
Quote this message in a reply
Member
Posts: 25
Joined: 2011.08
Post: #19
Ok... But because of that:
Quote:What you're seeing is a fundamental difficulty when dealing with transparent objects, and the source of many headaches for graphics programmers. What happens is that when you draw a quad with a partially-transparent texture in the foreground, the entire quad is written to the depth buffer, so anything subsequently rendered behind it will fail the depth test and not get rasterized.
I'll have to decide the order myself, because I'm using transparent textures, so, if there's no reason to let GL do the same thing again. So in that case it would be kinda useless... Or I'm still not understanding something. Blink
Quote this message in a reply
Member
Posts: 96
Joined: 2011.07
Post: #20
I don't know if it really matters. It depends what you want to do really. If you think of Video DJs they don't know exactly how their mixers work but they do put up a party.

Check this out:

This gradient...
[Image: Bug%20Light.png]

Is drawn on top of these bugs to create a light effect.
[Image: IMG_0003.PNG]

The same gradient is drawn under the centipede to make it glow. Everything is a quad here drawn from bottom to top.

respect,
pk

iFrog is coming.
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #21
(Aug 24, 2011 09:07 AM)ipeku Wrote:  Now, if you have the depth buffer on, OpenGL will decide on the drawing order. Depending on what you're doing whether it's something in the shaders (multiplication or addition, etc.) or a different blending equation the outcome will be different.

With the depth buffer off you control the drawing order yourself. Hope that explains something.

That isn't right. The drawing order is always the same, if depth testing is used or not: every triangle is drawn in exactly the order you submit it.

What the depth test changes is that any given pixel may be discarded when it's turn is reached, rather than being drawn. But the draw-vs-discard decision is still strictly made in triangle submission order.
Quote this message in a reply
Member
Posts: 96
Joined: 2011.07
Post: #22
Hmm, that's odd. I was under the impression that depth test sorts out the drawing order before everything is painted (using the painters algorithm).

This is what Beginning iPhone Games Development has to say about it:

"OpenGL, like most every other graphics display API, uses what is known as the painter's algorithm to draw things to the screen. This means that the first thing that you send to the engine gets drawn first, and the second thing will get drawn second; if they occupy the same screen space, then the second thing will be on top of the first thing."
[...]
"When you set USE_DEPTH_BUFFER to 1, this method will also generate a depth buffer that the engine can use for depth sorting. (To use depth sorting, you also need to turn it on in the engine like so: glEnable(GL_DEPTH_TEST). When depth sorting is active, the engine will take all your draw calls and sort the various vertexes based on how far away they are from the camera, and render them in the proper order."

respect,
pk

iFrog is coming.
Quote this message in a reply
Moderator
Posts: 1,562
Joined: 2003.10
Post: #23
(Aug 31, 2011 08:58 AM)ipeku Wrote:  This is what Beginning iPhone Games Development has to say about it:

"When you set USE_DEPTH_BUFFER to 1, this method will also generate a depth buffer that the engine can use for depth sorting. (To use depth sorting, you also need to turn it on in the engine like so: glEnable(GL_DEPTH_TEST). When depth sorting is active, the engine will take all your draw calls and sort the various vertexes based on how far away they are from the camera, and render them in the proper order."

This is partially correct, but doesn't tell the whole story. The PowerVR SGX (iPhone's GPU) uses tile-based deferred rendering, and does in fact sort primitives by depth before rasterizing them. However, this is a feature of that particular GPU, not OpenGL itself. On the desktop (including the iPhone simulator, if I'm not mistaken), you still need to do your own depth sorting for things to look right. If you only ever care about running on iPhone hardware, though, you may be able to get away without it and just let the hardware handle it for you.
Quote this message in a reply
Member
Posts: 96
Joined: 2011.07
Post: #24
You know, that tile-based deferred rendering thing I never got working in practice. Pardon me asking here in Vunterslaush's thread but, should it "kick in" even if depth test is off? So far if I draw a space station at z=500 but draw it last it still renders on top (of things that should be in front of it).

respect,
pk

iFrog is coming.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #25
OpenGL works "as if" the depth buffer contains a per-fragment depth value, and updates the color buffer only if the incoming fragment's depth passes the depth test relative to the depth buffer value if depth test is enabled, or always updates the color buffer if depth test is disabled.

The fact that the PowerVR does tile-based deferred rendering is a red herring.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #26
(Aug 24, 2011 09:39 AM)vunterslaush Wrote:  I'll have to decide the order myself, because I'm using transparent textures, so, if there's no reason to let GL do the same thing again. So in that case it would be kinda useless... Or I'm still not understanding something. Blink

Traditional 3D engines tend to work this way:
1) Enable depth testing/writes, disable blending.
2) Draw opaque objects front to back.
3) Leave depth testing on, disable depth writes. Enable blending.
4) Draw transparent objects and particle effects back to front.
5) Disable depth testing and draw light flares, glows, or other special effects.

#2 is front to back so that faraway objects draw fewer wasted pixels. The sorting can be really coarse though. With tile based deferred rendering, the order is not important. It does that for you so it doesn't draw any unnecessary pixels at this point. **
#3 Transparent objects are drawn in a separate pass because you need to carefully control the drawing order so the blending is correct.

** Only when depth testing and writes are turned on IIRC

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 25
Joined: 2011.08
Post: #27
(Aug 31, 2011 01:58 PM)Skorche Wrote:  
(Aug 24, 2011 09:39 AM)vunterslaush Wrote:  I'll have to decide the order myself, because I'm using transparent textures, so, if there's no reason to let GL do the same thing again. So in that case it would be kinda useless... Or I'm still not understanding something. Blink

Traditional 3D engines tend to work this way:
1) Enable depth testing/writes, disable blending.
2) Draw opaque objects front to back.
3) Leave depth testing on, disable depth writes. Enable blending.
4) Draw transparent objects and particle effects back to front.
5) Disable depth testing and draw light flares, glows, or other special effects.

#2 is front to back so that faraway objects draw fewer wasted pixels. The sorting can be really coarse though. With tile based deferred rendering, the order is not important. It does that for you so it doesn't draw any unnecessary pixels at this point. **
#3 Transparent objects are drawn in a separate pass because you need to carefully control the drawing order so the blending is correct.

** Only when depth testing and writes are turned on IIRC

First let me start by saying that I didn't fully understand everything you said, as I'm new to this and I didn't get / nor plan to get to the complete bottom of OpenGL...
BUT since currently my main concentration is 2d games, that are mostly sprite based, and most of my sprites are going to be transparent, will using depth testing still give me any benefits?
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #28
No, depth testing gives you very little to no benefit for 2D games. If the sprites have 1 bit alpha you could use alpha testing, but that doesn't perform as well on the iPhone as it does on the PC and you might as well just not use it. You can't use depth testing on stuff that is partially transparent as it wouldn't have a depth value to record.

For 2D stuff with full alpha transparency, you just draw everything back to front. As has been said before, if you want better performance, pack all of your sprites into atlases to use as few textures as possible. When drawing, pack each sprite's geometry into a buffer until you need to change the texture, then submit that batch, set the new texture and repeat.

Also, VBOs do you little good if you are submitting fresh data every frame (IIRC). They generally for when you have a mesh that you draw over and over and want to keep it in video memory.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #29
You can get better streaming performance using VBOs than you can without, too. YMMV, depending on your data, your hardware, and how you use the API.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #30
Hmm. Ok. I was under the impression that if you weren't sharing any data between frames that a VBO was just more work for the same amount of performance.

Although... Obviously don't spend too much extra time optimizing something before you know it's too slow. For instance, on our Twilight Golf game we were able to draw a few dozen sprites at 40-60 fps on a 1st gen iTouch along with all the light/shadow rendering and physics. We atlases the sprites but didn't batch any sprite geometry. It was a very simple engine to write and the performance was fine for the complexity we wanted. Spending any more time on optimizations would have just been a waste of time.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  OpenGL ES questions regarding 2D mixed with 3D jeonghyunhan 5 6,310 Jun 20, 2009 03:54 PM
Last Post: jeonghyunhan
  OpenGL: glRotate and some 3D questions. mikey 1 3,847 May 19, 2009 05:11 PM
Last Post: ThemsAllTook
  Basic OpenGL questions Mercy 5 4,732 Dec 23, 2008 10:25 AM
Last Post: AnotherJake
  Some OpenGL 2D questions oskob 16 9,633 Oct 30, 2008 12:12 PM
Last Post: Wowbagger
  Dreaded noob questions: OpenGL in a Cocoa App 5thPeriodProductions 5 4,695 Apr 10, 2006 11:08 AM
Last Post: 5thPeriodProductions