Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (521)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (589)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Ordering draw calls for alpha blending  (Read 1288 times)
0 Members and 1 Guest are viewing this topic.
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Posted 2014-07-05 12:01:02 »

Hey!

I recently ran into a problem where having multiple calls to opengl to draw translucent geometry produced some funky results. I googled it, and I believe the problem has something to do with having to order the draw calls from back to front.

I was curious; how should I go about doing this?

My game features an infinite world, split into chunks. Each chunk is 1 VBO. I can order the VBOs from back to front no problem. But will this fix the problem,? Or do I need to order the draw calls within the VBO too? Wouldn't that be quite awkward to do, especially if you have a face that has 2 vertices behind another face, but 2 vertices in front of that same face?

I'm a little puzzled if I have to be honest. The only thing I know is that the weird alpha drawing only happens between chunks. This leads me to believe I only need to order the separate VBOs rather than the inner calls to openGL to draw the faces...

Anyway, thanks:P
Offline Hermasetas

Senior Devvie


Medals: 6
Projects: 2
Exp: 3 years


I do gamez, yes!


« Reply #1 - Posted 2014-07-05 13:10:46 »

I can order the VBOs from back to front no problem. But will this fix the problem,?

Try it Tongue

Also some pictures might help Smiley
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #2 - Posted 2014-07-05 13:32:01 »

Just wondering if anyone had any experience with it, before I jump in and do something:P
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline orange451

JGO Coder


Medals: 17
Projects: 2
Exp: 4 years


Your face. Your ass. What's the difference?


« Reply #3 - Posted 2014-07-05 17:06:42 »

You can order everything based on distance to the camera.

Working on a nice FPS in lwjgl Smiley http://i.imgur.com/q4uFqBS.png
Feel free to message me if you're interested!
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #4 - Posted 2014-07-05 17:17:33 »

But the point is, do i need to order every draw call, or just the order in which the VBOs are drawn?
Offline Longarmx
« Reply #5 - Posted 2014-07-05 17:25:44 »

I experienced this problem with my 3d world. Instead of sorting everything back to front, I just discarded the pixel with a custom shader.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
varying vec2 texCoords
out vec4 color;
uniform sampler2D sampler

void main()
{
     vec4 textureColor = texture2D(sampler, texCoords.xy);

     if(textureColor.w <= 0.01) // If the pixel is basically transparent
          discard; // Throw this fragment away;

     color = textureColor; // Else assign this fragment to the pixel's color
}


Unfortunately, this method only works for completely transparent textures. If you want translucency, then you will have to sort back to front instead of using this method.

Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #6 - Posted 2014-07-05 17:29:45 »

But how could you sort it back to front if half the vertices of 1 poly are behind, and the other half are in front?
Online theagentd

« JGO Bitwise Duke »


Medals: 361
Projects: 2
Exp: 8 years



« Reply #7 - Posted 2014-07-05 20:16:48 »

Most games don't have anything transparent except for particle effects, e.g. smoke, fire, sparks etc, which are easier to sort as they are flat quads facing the camera (so no impossible scenarios can occur). Games generally completely avoid having semi-transparent geometry due to the complexity of handling that. The closest thing available is alpha testing, which isn't really transparency. It's exactly what Longarmx wrote about, where you discard pixels that are "too transparent", effectively achieving binary transparency (either fully opaque or fully transparent).

Myomyomyo.
Offline basil_

« JGO Bitwise Duke »


Medals: 68
Exp: 12 years



« Reply #8 - Posted 2014-07-06 13:34:01 »

order independent blending is really hard to do right.

sorting triangles will only approximate correct results; there are too many special cases when simple sorting fails ... like overlapping triangles.

state of the art of dealing with transparency is using per-pixel-linked-lists afaik, using a so called "a-buffer". a list of values per pixel, sorted per pixel and drawn blended back to front. too bad it requires rather recent hardware, i think gl 4.3+.

some random google results :

http://www.slideshare.net/acbess/order-independent-transparency-presentation
http://www.cescg.org/CESCG-2011/papers/TUBudapest-Barta-Pal.pdf
Offline Roquen
« Reply #9 - Posted 2014-07-06 14:28:29 »

It'd be interesting to think about a hybrid of the weighted OIT with fixed number of layers and no sorting per say.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #10 - Posted 2014-07-06 15:06:56 »

Hm, okay. I guess I should abandon this then - I was going to have all of the terrain above a certain height translucent, so that you could not only see a 'cross section' of the terrain but also the full shape of the terrain.
Offline Roquen
« Reply #11 - Posted 2014-07-06 19:10:26 »

@basil_:
 Skip on the a-buffer: https://software.intel.com/sites/default/files/i3d14_mlab_preprint.pdf

further out: http://www.nvidia.com/docs/IO/88888/StochTransp-slides.pdf

Possible today on low-end: http://casual-effects.blogspot.fr/2014/03/weighted-blended-order-independent.html
Offline basil_

« JGO Bitwise Duke »


Medals: 68
Exp: 12 years



« Reply #12 - Posted 2014-07-06 20:59:52 »

aah cool, thanks! Smiley I'd love to skip a-buffers. they cannot be speedy or easy on memory usage.

stochastic blending is about abusing msaa buffers to do order independent "dither" type blending ?
Offline Roquen
« Reply #13 - Posted 2014-07-06 21:32:16 »

stochastic is pretty far out.  yeah: the high view is many samples of some fencing/dither pattern per pixel (a la old software rendering trick).
Offline Roquen
« Reply #14 - Posted 2014-07-06 21:47:29 »

Other random thoughts are the volumetric stuff: fourier opacity mapping, extinction transmittance maps, half-angle slicing. 
Offline basil_

« JGO Bitwise Duke »


Medals: 68
Exp: 12 years



« Reply #15 - Posted 2014-07-11 11:19:58 »

reads really good :

http://www.nvidia.com/docs/IO/88888/StochasticTransparency_I3D2010.pdf
Offline Roquen
« Reply #16 - Posted 2014-08-18 10:07:19 »

Efficient Rendering with Tile Local Storage:  http://community.arm.com/docs/DOC-8916
Pages: [1]
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xFryIx (58 views)
2014-11-13 12:34:49

digdugdiggy (37 views)
2014-11-12 21:11:50

digdugdiggy (30 views)
2014-11-12 21:10:15

digdugdiggy (26 views)
2014-11-12 21:09:33

kovacsa (48 views)
2014-11-07 19:57:14

TehJavaDev (51 views)
2014-11-03 22:04:50

BurntPizza (51 views)
2014-11-03 18:54:52

moogie (66 views)
2014-11-03 06:22:04

CopyableCougar4 (65 views)
2014-11-01 23:36:41

DarkCart (150 views)
2014-11-01 14:51:03
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!