Java-Gaming.org Hi !
Featured games (87)
games approved by the League of Dukes
Games in Showcase (649)
Games in Android Showcase (181)
games submitted by our members
Games in WIP (700)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 108
1  Java Game APIs & Engines / OpenGL Development / Re: Post-processing effects 101? on: 2016-02-13 09:19:55
The fastest and lowest quality of them all, yes.
2  Java Game APIs & Engines / Java 2D / Re: Light blocks up on: 2016-02-11 11:22:28
Thanks,

Is it possible to pass to the shader if the tile/sprite needs to be lit up?

1  
2  
3  
4  
5  
6  
7  
8  
9  
uniform int renderMode; 

void main() {
    if(renderMode == 0) {
        //render normally
    } else if(renderMode == 1) {
        //lighten tiles color up...
    }
}


Thanks
That is possible, but extremely inefficient. You'll want to draw all tiles with a single draw call, so at least make renderMode a vertex attribute, not a uniform variable.
3  Java Game APIs & Engines / Java 2D / Re: Light blocks up on: 2016-02-10 15:32:08
Your image isn't working.
4  Java Game APIs & Engines / OpenGL Development / Re: Post-processing effects 101? on: 2016-02-10 15:31:07
Postprocessing is just any effect that processes the entire rendered screen. The most simple effects are stuff like color correction, tone mapping, blurring, sharpening, etc. These are fairly simple to implement using a shader with a couple of texture samples and a tiny bit of math. You also have a couple of anti-aliasing postprocessing shaders out there, with FXAA being the simplest to get going. Then there are more advanced postprocessing algorithms, like screen-space ambient occlusion, motion blur, depth of field, bilateral blurs, custom multisample resolves, temporal supersampling, etc that are much harder to get right and may require multiple fullscreen passes and tricks.

If you have any specific questions I'm sure I can answer them.
5  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-02-10 15:09:52
I've only skimmed the paper.  I'm going to wait for the reference version...the conference is in a couple of weeks.
If that works as they say it does, using less than 16 bytes per pixel with only a single pass and without any need for OGL4+ features, it's completely revolutionary. The result looks correct for the glass, but the lack of tests with smoke particles and similar stuff is a bit suspicious.
6  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-02-10 10:14:38
Several questions about your rendering:

  • What did you need 8 render targets for in the first pass?
  • How does your new render system work with the compute shader? Do you still output to the render targets and then each instance of the compute shader processes the 8 vec4s across the 8 RT?
  • How is memory controller load reduced from 80% to 2%? Isn't the same data being processed by the compute shaders instead of fragment shaders now?

I've been getting very interested in how OIT works!

I'll go with the stochastic OIT I implemented to explain it. Stochastic OIT basically means that you have a number of samples per pixel, and each sample has a chance to pass based on the alpha of what covers it. On average, this produces the correct result. The old algorithm looked like this:

In the first pass I write to 8 RGBA16 render targets with GL_MIN blending. I'm basically emulating 32 separate depth buffers this way (using MSAA and a coverage mask requires OGL4+ and limits samples to 8 ), and the shader outputs either <depth> for a sample that randomly passes, and <1.0> when it doesn't. This part is purely bandwidth bound. In the second pass, I basically do weighted blended order-independent transparency (WBOIT) using the 8 textures from before as the weighting function. This means writing to 1xRGBA16F and 1xR16F render target and reading the right pixel from all 8 render targets, then doing a step comparison between the depth of the current particle and all stochastic samples. This is also heavily bandwidth bound as the texture data doesn't fit in the texture cache. Finally, there's a fullscreen pass to resolve the weighted sum computes, writing to the final output RGBA16F render target.

For a compute shader, none of the textures are needed. I can replace the 8xRBGA16 with a vec4[8] and write to those instead. Since they're just registers in the compute shader, they never go out to main memory. Similarly, reading those samples is again just a register read, so texture hardware or main memory is never involved. I can even do the final weighted sum resolve in the compute shader as well, and finally just do an image-store write to the output RGBA16F render target. Only for this final write is main memory actually used.

On OIT: There's a new paper by Morgan McGuire & Michael Mara: http://graphics.cs.williams.edu/papers/TransparencyI3D16/
Yeah, I haven't entirely figured out what they're doing that's actually new in that one. Still working on it.
7  Game Development / Game Mechanics / Re: Calculating dFdx and dFdy of texture coordinates in 2D manually on: 2016-02-09 23:35:22
Sure, check out dFdxLinear()/dFdyLinear() here: https://github.com/JOML-CI/JOML/blob/master/src/org/joml/Interpolationf.java
8  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-02-09 22:38:39
A few months ago I saw these slides: http://www.slideshare.net/DevCentralAMD/holy-smoke-faster-particle-rendering-using-direct-compute-by-gareth-thomas

Apparently they found that foregoing rasterization of particles and instead going with a tiled compute shader was actually faster than hardware blending. In essence they divided the screen into tiles, binned all particles to said tiles and then had a compute shader "rasterize" those particles, blending into a vec4 completely inside the shader (no read-modify-write to VRAM). They also implemented sorting of particles in the compute shader.

I took a slightly different approach. I've been experimenting with quite a few order-independent transparency algorithms in the past few months/year, and I've got stochastic transparency, adaptive OIT, fourier-mapped OIT (hopefully I'll get around to posting my bachelor thesis on this soon) and a reference CPU-side sorting simple renderer. So as a first test, I tried merging all 3 passes stochastic transparency into a single compute shader. Instead of writing to 8xRGBA16F render targets in the first pass, and then reading all those textures in the second pass and finally doing the weighted average resolving in a final fullscreen pass, I simply use 8 vec4s in the compute shader, immediately do the second pass again writing to local variables and finally doing the resolve and outputting the final RGBA of all particles blended together correctly, all in one (not so) massive shader. I currently lack the tile binning, and a lot of calculations are currently done on the CPU that need a lot of optimizations, but the GPU performance looks very optimistic. In some cases with a large number of particles covering the entire screen, the compute shader achieves almost twice the framerate of my old algorithm, and even more impressively at the same time reduces memory controller load from 80% to a meager 2%. The next step would be to port adaptive OIT to a compute shader. This would be even more interesting at it would eliminate the need for a linked list, as I can just compute the visibility curve as I process the particles. This would in theory allow AOIT to work on OpenGL 3.3 hardware if I just emulate a compute shader with a fullscreen fragment shader pass.

The biggest problem with this approach is that I would need to have every single piece of transparent geometry available in the compute shader, and I wouldn't be able to have different shaders for different particles. However, it would be possible to only use the tiled approach to construct the visibility curve for AOIT in using a tiled compute shader, output the curve to textures and finally proceed with the second pass as usual. That would allow me to have fairly complex shaders for the particles (as long as they don't modify alpha in a complex way) and still have the flexibility of my old system.

I don't really have any good pictures I'm proud of to show off of all this, but hopefully I'll get some nice screenshots in the end. >___<
9  Game Development / Game Mechanics / Re: Calculating dFdx and dFdy of texture coordinates in 2D manually on: 2016-02-09 22:13:53
KaiHH was nice enough to help me get what I needed implemented into JOML! Thanks, Kai!
10  Game Development / Game Mechanics / Calculating dFdx and dFdy of texture coordinates in 2D manually on: 2016-02-09 17:13:23
Hello.

I have this problem where I want to calculate the gradient of the texture coordinates of a 2D triangle. I have:
 - three 2D positions XY for each vertex of the triangle, in screen pixels.
 - three 2D texture coordinates ST for each vertex of the triangle, in the range [0-1].

I want to calculate the gradient along X and Y for the texture coordinates, but I can't remember how to do that from my linear algebra classes, and my Google-fu is failing me. In other words, what's the change in the texture coordinates when I go one pixel to the right (dFdx) or one pixel up (dFdy)?

The ultimate goal is to derive a function F(XY) = ST, so that I can calculate the texture coordinates of any pixel on the screen quickly (even points outside the triangle). It will have the form F(XY) = X*dFdx + Y*dFdy + offset, with the 2D offset being possible to calculate once I have dFdx and dFdy.
11  Discussions / Miscellaneous Topics / Re: What's your "game dev dream" on: 2016-02-09 13:29:57
I'd really like to be able to a breathtakingly beautiful island using LWJGL, but as of now I'm unable to realise this dream as I simply lack the skill to do so. Of course, I'm still learning OpenGL, so I hope I'll eventually be able to accomplish this feat (it's a feat to me, but probably not to certain people on this forum *ahem* theagentd *ahem*).
Well, your first mistake is shading vertices. You have to do lighting per pixel nowadays. =PPP

Yeah, I know, I do the final lighting calculations in my fragment shader (which I'm pretty sure is also known as the per-pixel shader...right?).

Oh wait. OH SORRY, you were making a joke, weren't you? Yeah, yeah: I get it. ShadedVertex.

I lack a sense of humour, sorry.

EDIT: No, I actually don't lack a sense of humour.
Haha, jokes aside...

My interest lies in graphics programming, so I guess my dream is to have proper art to complement the shaders and stuff. Considering how hard it is to get decent artists for WSW, we'll see how that pans out. x_x
12  Discussions / Miscellaneous Topics / Re: What's your "game dev dream" on: 2016-02-09 07:54:27
I'd really like to be able to a breathtakingly beautiful island using LWJGL, but as of now I'm unable to realise this dream as I simply lack the skill to do so. Of course, I'm still learning OpenGL, so I hope I'll eventually be able to accomplish this feat (it's a feat to me, but probably not to certain people on this forum *ahem* theagentd *ahem*).
Well, your first mistake is shading vertices. You have to do lighting per pixel nowadays. =PPP
13  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-02-03 08:59:57
Spacescape is amazing.
14  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-01-28 11:58:15
Enlarging the fonts a lot does introduce quite a few problems. Bilinear filtering leaves a lot to be desired, so bicubic filtering is best if you want the best quality or smooth curves will look like they're built from sharp edges. You can also get problems with bit precision (only 8 bits with large distances cause problems) and texture interpolation precision. Most hardware only supports 256 different values between the interpolated values, so if you oversharpen edges you may end up with huge artifacts. All in all, you're better off not upscaling more than 2x or so of the original font size, but at least I won't need multiple font textures for different font sizes.

Zooming out, it looks perfect until around font size 10. Any lower and the glyphs will turn into white rectangles due to mipmaps being too small causing glyphs to bleed together. With enough padding you can go lower, but at that point the text is already hard to read (although that might be because I'm on a 1440p monitor...).
15  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-01-28 09:53:15
@theagentd: one distance per sample?  What's interesting to see is close in at (what should be)  sharp angles and very small...assuming either will happen.
Yes, only one distance field. I don't specifically treat sharp edges differently. Generating such distance fields seemed really complicated. What this sharp angled and very small thing is that you're so fascinated with I can only imagine...
16  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-01-27 20:10:47
Distance field fonts!
...
I hate to be a nit-picker, but is there a thin vertical white artifact (|) between some letters? Such as before the first i in '|ipsum', and on the second line before the second i in 'suscip|it'. Seems to only affect i's as far as I can tell.
Heh, you're right. It's due to texture bleeding from insufficient padding. I'll have to reconvert the font. xd It happens more frequently for smaller fonts, but I thought this was big enough...
17  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-01-26 16:32:59
Distance field fonts!



Features:
 - Scales perfectly fine thanks to distance field fonts. Perfect anti-aliasing and quality at font sizes 10 to 200.
 - Cursive doable by just modifying vertex coordinates of the glyph quads.
 - Bold doable by just modifying distance field calculations.
 - Custom font shaders to allow for outline and shadow casting effects.
 - Manual line breaks on \n, automatic line breaks if a word would cause the line to become too long, and panic line breaks in the middle of words that are wider than the limit by themselves.
 - String width/height queries.
 - Support for command parsing in the form of {command}. The parsing support is in, but I've yet to implement the commands to change color/cursive/bold/etc in the middle of a string in a single batch.

Technical:
 - Fast, uses batched rendering. The multi-line string in the picture is actually rendered with one call to drawString() and with one draw call!
 - Font "profiles" combine a font texture and a shader, plus size, color, etc to allow the same font and shader to be reused in any number of combinations of fonts, shaders, size, color, etc.

EDIT: Getting 3500 FPS with the above text, and it's actually CPU limited. The above screenshot was taken with MSAA to anti-alias the bounds frame. >___> MSAA doesn't affect the actual font quality at all.
18  Game Development / Newbie & Debugging Questions / Re: Modern OpenGL & Shaders on: 2016-01-24 00:15:14
Big +1 for JOML. They have a perfect MatrixStackf class which has all the functions of the old OpenGL matrix stack, plus much more. It's all lightning fast too. Seriously, check that shit out.
19  Game Development / Game Mechanics / Re: Best data structure for triangle collision meshes on: 2016-01-24 00:05:46
+1 for Rtree. if you want i can throw my version at you. (not that it is bug-free or neat to read)
I'd really like that! I'm currently exploring some alternatives, but more information would be great! How did your construction code work? Was it the R*-tree version?
20  Game Development / Networking & Multiplayer / Re: Lag Compensation on: 2016-01-23 21:16:14
If you try to predict the movement of objects you get the problems you worry about. It's fairly easy to assume that objects will continue at the same speed, but this causes big problems when there are sudden changes. If you have a player standing still and then suddenly start moving, the message that s/he started moving will be delayed meaning that when the other players receive this message he'll suddenly snap to his predicted position. The same problem happens when the player stops, at which point the extrapolated player will suddenly teleport back to where he stopped.

Valve don't extrapolate positions. You will be displaying a delayed version of the world if you use interpolation, which is the standard nowadays. In this case you simply try to make sure that the world (other players, physical objects, etc) look smooth by interpolating between the state you get to reduce stuttering. All objects will be delayed by the ping, but at least they're 100% smooth. I believe I read somewhere that the Battlefield games use interpolation for twitchy character movement, but extrapolation when dealing with vehicles because they simply can't change their speed quickly and mostly just continue in the same direction they're going.

However, each client is a bit flexible when it comes to their own players. When you move in the source engine the game sends a movement command to the server, but the game moves your character immediately without waiting for a response. As long as the player isn't too far away from the last confirmed position from the server, the client is allowed to move things before getting confirmation. So the client doesn't ignore the server when it says where the player is, but it doesn't enforce it completely to reduce perceived lag. If you've ever heard of "rubberbanding", it happens when the client and the server disagrees and the player is suddenly snapped or slowly pulled to his correct position. Most games are simple enough that this never happens unless your ping is fluctuating a lot.
21  Game Development / Game Mechanics / Re: Best data structure for triangle collision meshes on: 2016-01-22 01:05:07
I decided to do a 2D test implementation to get a feel for it. I've got leaf node generation working I think.

Evenly distributed points in a circle


Concentration of points in the center


For evenly distributed points, it works fairly well. It can't handle concentrations too well, but I think it'll work well, as an evenly covering terrain is fairly coherent. A 3D implementation would probably be a bit more complicated. From here on I'm a bit unsure about how to proceed. I've generated the leaf nodes but there's little documentation on how to build the rest of the tree downwards from here.

For 2D, I calculate the following values:
1  
2  
int tilesNeeded = divideRoundUp(count, nodeCapacity); //count / nodeCapacity rounded up
int tilesDim = (int)Math.ceil(Math.sqrt(tilesNeeded)); //sqrt(tilesNeeded) rounded up


For 3D, I'd have to replace the sqrt() with cbrt(), but I recon that this will be unoptimal. There's a big risk that our levels will be elongated in some direction, most likely either very flat, very tall or corridor-like. It seems like modifying the tiling to take this into account would be a good idea. Weighting the number of tiles along each axis by the dimensions of the level volume's dimensions sounds like it could improve the shape of the leaf nodes of the tree.
22  Game Development / Game Mechanics / Re: Best data structure for triangle collision meshes on: 2016-01-21 19:52:11
I would have a separate datastructure for dynamic objects if possible, at least when auditioning the R-Tree structure, as the insertion and deletion functions are where the bulk of the complexity is.
Yeah, it sounds good to start with simply constructing the tree.

Let's see if I've gotten this right...
 - Each node seems to have a fixed number of maximum children, and children can be either triangles (in my case) or other nodes.
 - Each node's AABB is the box that can fit all children's AABBs.
 - The goal of the splitting algorithm is to minimize overlap between nodes on the same level, avoid elongated volumes and maximize the number of children of each node.
 - R*-trees differ from R-trees by somehow optimizing the tree gradually by removing random triangles when a node is split to child nodes and reinserting them again.

The big question mark is how the splitting is supposed to work. I think I understand how the resulting structure is supposed to look, and like you said the actually complex part seems to be constructing the tree.


The 2 query types could be potentially done in parallel as well, although they might be too fast to gain much.
The joke's on you! I'm already doing multiple queries in parallel on my quad tree. =3 The physics are entirely threaded actually and pretty much scaling linearly with cores, including body-body collision detection and response.
23  Game Development / Game Mechanics / Re: Best data structure for triangle collision meshes on: 2016-01-21 19:37:20
Quote
If you know of a small minimal implementation of R* trees that'd probably help me a lot.
All you would need is two functions: bulk-load construction (since you have pre-known, static data, no insertion/deletion functionality is required) and intersection query, correct?
Hmm. Although 95%+ of the triangles would be static, there would be some meshes (buildings, some props) that would need to be modified during the game. Being able to insert/delete data would be useful for those, but it would be possible to handle dynamic objects in a separate way as well since so much of the data is static.
24  Game Development / Game Mechanics / Re: Best data structure for triangle collision meshes on: 2016-01-21 19:21:22
Quote
Do you have any good resources for them?

Mostly just the paper(s) cited on wikipedia: The R* Tree

I forgot that STR bulk loading works on  regular R-trees, so I'd just start there; here's that paper: STR
You know it's good if NASA came up with it!  Pointing
Alright, I'll look into it, although it'll probably take me a few days to "absorb" it all. If you know of a small minimal implementation of R* trees that'd probably help me a lot.

A big level would be ~600 000 to 1 000 000 triangles.
Why ?)
Do you use any sort of Lod collision mesh?
This is meant for the terrain. We will use a lower res collision mesh for the terrain, but it will still be very big.


up:
collision response for the triangles
You really use triangles in collision? ^^
no one doing so - they change render model to -> collision with primitive parts like sphere, tube, box, etc

http://counterstrike.wikia.com/wiki/Hitbox
Hitbox == collision model
Our objects are already treated as spheres. What I want triangles for is the terrain, which the Source engine most definitely handles the same way as me.


EDIT: Managed to cut a significant chunk of the query CPU time from my quadtree by optimizing memory layout. Each quadtree node had a Bounds3D object keeping track of the 3D bounds of the node. I instead made the node EXTEND Bounds3D meaning the bounds variables were stored together with the node instead of at a separate location. This gave me a nice 18% performance boost.
25  Game Development / Game Mechanics / Re: Best data structure for triangle collision meshes on: 2016-01-21 16:11:51
R-Tree? Should be faster than  Quad/Oct-trees I believe, it's at least highly tune-able. Look at the R* variant with it's Sort-Tile-Recursive construction method since you can exploit the fact that your data is static. Those are stupid fast for spatial queries in my experience.
R-trees sound really interesting! I did some Googling, but I couldn't find any code specific for R*-trees. Do you have any good resources for them?


for terrain collision in shard master i get the X-Z (Y being up) coords of the player and find the height on the triangle it is currently on at point (X, Z) using
It's not a heightmap terrain. The triangles can be at arbitrary positions, so this won't work.

Can you probably make use of temporal coherence (the player does probably not move from one side of the level to the other side in one physics frame/tick) and associate/cache/store some deeper quadtree node with the player, so that you don't have to check all triangles in your level every time? Or are huge triangles duplicated into many nodes the real problem?
Triangles aren't duplicated for each node. I found that placing triangles in the smallest node that fit them placed a crapload of triangles in the root node if they simply overlapped the center of the level. I ended up forcing triangles into the node that they're centered on and computing the 3D bounds of each quad-tree node. Bounds for each node are used when searching through it. This worked much better for me. From what I've read about R-trees this seems a tiny bit similar to what's done there.

Can you probably make use of temporal coherence (the player does probably not move from one side of the level to the other side in one physics frame/tick) and associate/cache/store some deeper quadtree node with the player, so that you don't have to check all triangles in your level every time? Or are huge triangles duplicated into many nodes the real problem?
Yeah, it's usually very temporally coherent, but I'm not sure how to implement it in a sane way. Feels like the caching overhead would be more than the wins.

One big issue you might have is that a quadtree implemented in Java is basically scattered all over memory, which instantly removes much of its performance. If you were to move to a packed memory format in a ByteBuffer (Riven's structs for example or that thing Spasi was working on) you'd get much better performance.

Another thing you might think about is reducing the granularity of your quadtree... no point in getting to the point where you're storing just a few triangles in each node: it causes an explosion in the size of the quadtree. While that might only mean another couple of nodes in depth to traverse, it also means jumping all over memory even more, and I suspect memory is the slow part.
I also think that the memory accesses are the slow part. I've tried to modify the maximum depth and the split threshold to the empirically best values I've found.

It might be interresting to know how huge 'huge' is?
A big level would be ~600 000 to 1 000 000 triangles.

It seems like the biggest problem right now is that simply traversing the quad tree is very slow. Finding an alternative data structure sounds like a good idea.

Before trying something entirely new, it might be worth optimizing the current structure. My favorite information on the subject is Pitfalls of Object Oriented Programming. Not entirely possible in Java (until we get something like "packed arrays" in Java 10+), but the idea still applies. If you allocate all node data per tree level in one batch, most likely they will end up contiguous in memory. The two Java-specific problems here are a) GC moving the objects around (though that will be done in "batches" too) and b) the object header overhead. Both can be solved with off-heap data, via NIO buffers or a struct framework, but that sacrifices a bit of computation performance (many optimizations are coming in Java 9 that might change this).
Interesting point and slide! I might actually try this out if I have the time! Gonna do some small improvements to try to improve memory performance first to see if it'll be worth it first.

It's not inconceivable that you could actually do the quadtree in native code and get the best of both worlds - assuming the impedance mismatch between Java and C isn't too onerous.
Hmm... My current quad tree relies on callbacks from the query function. I would really prefer avoiding native code. x__x
26  Game Development / Game Mechanics / Best data structure for triangle collision meshes on: 2016-01-21 02:51:15
I have a huge number of static triangles forming the collision mesh of the world. I'm currently using a quad tree here, but it's very slow. There are two main problems I want to solve right now:
 - Using a quad tree means that it works the best for flat levels, but we're planing on making levels with more vertical movement. Therefore, an actual 3D structure would be preferable.
 - The current quad tree is slow as hell. In some extreme cases the quad tree query takes up 80% of the CPU time of the game since Kai helped optimize JOML for the actual collision response for the triangles (thanks Kai!).

It seems like the biggest problem right now is that simply traversing the quad tree is very slow. Finding an alternative data structure sounds like a good idea.
 - Octree: Well, supports 3D but will be even slower to traverse.
 - 2D grid: Still "flattens" the data structure, won't work well with vertical levels. Also, the triangles are arbitrarily big and should preferably not have to be split up.
 - 3D grid: Sounds like a great idea, but the triangles are arbitrarily big and should preferably not have to be split up.
 - BSP tree: Not entirely sure how this would work, but I get the feeling that the "linked list" of nodes in this case would be even higher than for a quad tree, reducing performance even more.
 - Huh

Fixing a 3D grid to work with arbitrarily large triangles sounds like the absolute best solution here, but I can't figure out how to make it work. Duplicating triangles into all grid cells they overlap wouldn't work unless there's a way to avoid processing the same triangle once (randomly doubling the collision response of one triangle would break physics). Marking triangles as processed would be hard to multithread, and keeping track of which triangles that have been processed is costly to check against.

Any ideas?  Clueless
27  Java Game APIs & Engines / OpenGL Development / Screen-space self-shadowing on: 2016-01-19 03:18:40


Coded this yesterday. It's an implementation of screen-space self-shadowing. Think screen-space ambient occlusion, but instead of checking pixels around the center pixel I just raycast towards the sun to find any immediate occluders. Sadly it's hard to show this off without a comparison, so take a look at these TWO sets of images:

http://screenshotcomparison.com/comparison/158537/picture:0

This was rendered with fairly low-res shadow maps, allowing SSSS (lol) to really shine.



Normal shadow maps with wide filtering has some big problems. A wide PCF filter causes pixels angled towards a light to shadow themselves as the flat PCF filter "cuts" into the side slope. To fix that you need a high slope depth bias, which pushes shadows far away for shadow casters seen at a sharp angle from the light's perspective. This causes "peter panning", where the shadows appear to originate some distance away from the object, making it look like it's floating in the air. This looks very ugly and easily causes very visible artifacts where some places that are clearly occluded are still lit up.

Another big problem is the difficulty with getting object-scale self-shadowing, AKA small details shadowing other details. In many cases this requires a ridiculously big shadow map, and even with cascaded shadow maps (the above images use 6 cascades @ 1024x1024 each) precision is simply far to low when the camera is close up to provide any coherent shadowing of details like small ridges or fingers occluding each other. Sure, I could just increase the shadow map size to 4096x4096 and call it a day, but that's gonna cut a sizable chunk of my FPS away (not to mention 400MBs of VRAM for 6 cascades).

However, there's a cool little trick/hack you can do that is very similar to ambient occlusion. For ambient occlusion, you sample a number of pixels around each pixel to figure out if they're blocking ambient light to the center pixel. It can have a very nice effect despite only being able to work with the very limited data that's in the depth buffer. Now, shadow maps can handle large-scale shadows perfectly fine. We can get nice, soft shadows, but they suffer when the resolution is too low when the occluder and the ocludee are very close together. The depth buffer, however, is fairly accurate when looking in a 10-50 pixel radius around each pixel, which ambient occlusion has proven time and time again. So, I decided to simply raycast a few pixels away towards the sun for each pixel in an attempt to find an obvious occluder. It's far from perfect; the pictures above show the best-case scenario, but it has a lot of promise. For geometry much finer than the shadow map resolution that originally didn't get any shadows at all, this technique can add a nice sharp contact shadow bringing out a lot of detail. That the shadow map shadows are pushed away from shadow casters is no problem since SSSS (lolll) works almost perfectly in those cases, basically filling the gap. It only works in the worst cases of shadow maps where you can obviously both the occluder and the supposed-to-be-shadowed geometry, so they cover each other's weaknesses well.

There are of course times when the shadows get noisy due to missing information in the depth buffer, but this technique has a lot of promise as a band-aid to low-resolution shadow maps while being cheaper than increasing the resolution. I plan on doing some more research, but this looks very promising. In some cases 1024x1024 shadow maps + SSSS could have similar quality to 4096x4096 shadow maps only, although with softer distant shadows.
28  Game Development / Newbie & Debugging Questions / Re: How to rerender a VBO? on: 2016-01-18 04:03:37
glEnableClientState() makes OpenGL attempt to read data from a VBO. If you at any point draw something with immediate mode, or don't have a valid buffer for an attribute anymore or read out of bounds, you can crash the entire program. Example:

1. Draw model 1 with 100 vertices, each with 3D positions, texture coordinates and normals. glDisableClientState() is not called afterwards.
2. Draw model 2 with 5000 vertices, each with only 3D positions and texture coordinates. Potential for a crash here as the previous glNormalPointer() points to the buffer of model 1 and it's left enabled, meaning that the driver will read out of bounds of the VBO, potentially randomly crashing the JVM.

Making sure to always disable state you're not using anymore is a good idea.

The best solution is to keep track of the state of everything and only change it when it actually needs to be changed, as OpenGL commands have a lot of overhead. In the example above, you'd want to avoid disabling and enabling attributes inbetween drawing model 1 and 2. You'd realize that position and texture coordinates are already enabled and only disable normals (1 call), instead of disabling all 3 of them and enabling position and texcoords again (5 calls). This is probably overkill though unless you're drawing a crapload of models each frame.
29  Game Development / Newbie & Debugging Questions / Re: What type of rendering should I use? on: 2016-01-18 01:54:23
Anyways: Of course you should start learning shaders and modern OpenGL. I just wanted to get straight that the fixed-function pipeline is _still_ available. Cheesy

And I am just waiting for people to declare whole OpenGL "deprecated" once Vulkan comes out, saying "Vulkan is the future. You should totally and immediately only use Vulkan from now on."
Even though it would take like a thousand code lines to render even a single triangle with Vulkan.
And people will say "Yes, it's the way it is. And Vulkan is the way to go. And it has sooo many times better performance compared to OpenGL, with all its command buffers. And you can even do everything super-multithreaded and take care of every bit of allocated memory for yourself. And you have fine-grained control over the residency of resources on the GPU."
And people will cry tears and want to go back to OpenGL 1.1 when they first come into contact with Vulkan and realize that they get less done than before and need ten times the effort to do anything and have a hundred times more bugs/errors in their code. Cheesy

Vulkan is far from a replacement to OpenGL. Vulkan is an alternative that trades complexity for CPU performance, and OpenGL will keep on getting updates and live on. I wouldn't recommend people who aren't seriously interested in graphics programming to dive into Vulkan, and I probably wouldn't people who were interested in actually releasing games to use it either, since you're limited to fairly new cards (OGL4+ Nvidia cards, but only the absolute latest AMD cards). It'll take a few years until Vulkan becomes a serious alternative for most people. That obviously won't stop me from diving straight into it out of pure curiosity.
30  Game Development / Newbie & Debugging Questions / Re: How to rerender a VBO? on: 2016-01-18 01:47:53
glBufferData() reallocates the VBO.
Pages: [1] 2 3 ... 108
 
KaiHH (167 views)
2016-01-31 23:15:29

sci4me (158 views)
2016-01-23 21:47:05

sci4me (142 views)
2016-01-23 21:46:58

KaiHH (177 views)
2016-01-19 13:26:42

theagentd (261 views)
2016-01-05 17:10:00

ClaasJG (278 views)
2016-01-03 16:58:36

chrisdalke (270 views)
2015-12-28 06:31:21

Guerra2442 (278 views)
2015-12-25 03:42:55

Guerra2442 (282 views)
2015-12-25 03:27:21

theagentd (302 views)
2015-12-21 14:43:24
List of Learning Resources
by SilverTiger
2016-02-05 09:39:47

List of Learning Resources
by SilverTiger
2016-02-05 09:38:38

List of Learning Resources
by SilverTiger
2016-02-05 09:35:50

Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30

Rendering resources
by Roquen
2015-10-15 07:40:48
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!