Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (776)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 203 204 [205] 206 207
  ignore  |  Print  
  What I did today  (Read 3007942 times)
0 Members and 2 Guests are viewing this topic.
Offline princec

« JGO Spiffy Duke »


Medals: 1060
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #6120 - Posted 2018-09-21 08:53:24 »

You guys should put this in another thread, or this whole What I did today topic is basically just a slightly more persistent version of the Discord...

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6121 - Posted 2018-09-21 22:20:36 »

...or this whole What I did today topic is basically just a slightly more persistent version of the Discord...
That's fine with me.
Btw.: Implemented some form of "irradiance caching" (a separate compute shader is running continuously to sample over the hemisphere of all voxels' faces to gather ambient sky light. The rendering compute shader then just interpolates between the stored irradiances of all four vertices of the face hit by the eye-ray. As for temporal stability and noise this is far better than pure path tracing and I will probably keep it. Next will be point/torch light sources also scattering light onto nearby voxels, which need to be captured and cached as well.
<a href="http://www.youtube.com/v/6J7dMfPErRQ?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/6J7dMfPErRQ?version=3&amp;hl=en_US&amp;start=</a>
(at t=2s, t=50s and t=1m11s the irradiance cache is invalidated)

<a href="http://www.youtube.com/v/GyxVPSnDAqE?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/GyxVPSnDAqE?version=3&amp;hl=en_US&amp;start=</a>
Offline SkyAphid
« Reply #6122 - Posted 2018-09-22 00:07:50 »

This is cool as hell Kai. Can you make the voxels smaller for a higher resolution world? If you can, you should outright make some kind of small game with this tech.

it just werks
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6123 - Posted 2018-09-23 10:44:26 »

@Spasi pointed me to http://www.jcgt.org/published/0007/03/04/ which uses rasterization of screen-aligned rectangular sprites (using gl_PointSize in the vertex shader to control the size), which encompass a voxel in screen space (actually, the rectangle encompasses the sphere which itself encloses the voxel, so the rectangle is always bigger than what an actual screen-space bounding rectangle would be - but is easier to compute) and then subsequently do a ray-box intersection test in the fragment shader. This can be used for primary ray intersection with the scene. So I of course had to implement that as well (the GLSL source from the paper contained a few errors - maybe intentionally).
<a href="http://www.youtube.com/v/JhKmmSkl7IM?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/JhKmmSkl7IM?version=3&amp;hl=en_US&amp;start=</a>
Screenshot of the sprites:

They claim it is faster than just using pure rasterization of an optimized mesh, though I am sceptical. The inherent problem with their approach is that early-z does not work, because they need to compute and write to gl_FragDepth and do discard; in the fragment shader. So there is a lot of needless ray-box intersections going on in the fragment shader. But standard rasterization acceleration techniques apply to their technique, such as frustum culling and more importantly: occlusion culling. The big advantage of their algorithm then becomes that one does not need to build an optimized mesh anymore. Since I already have a BVH tree I am going to use it for frustum culling and GPU occlusion culling with conditional rendering as described here: https://developer.nvidia.com/gpugems/GPUGems2/gpugems2_chapter06.html
This should give lightning fast primary ray intersections with even hundreds of millions of voxels.

EDIT: Just added CPU frustum culling with the BVH tree, which was really trivial, since the big advantage of sorting the voxels first (using z-order-curve/morton code) before building the BVH tree is that every BVH node contains a contiguous range of voxels inside of it and most importantly, also inside of every of its child/descendant nodes. So each node (including the leaf nodes) only stores a "first voxel" index and a "last voxel" index into the voxels list (which only resides in the GPU buffer at that moment). So, I can just select how many clusters I want to test for frustum culling by selecting the respective BVH tree depth, iterating over all nodes up to that depth and issuing glDrawArrays(..., first, last-first+1) calls for the visible clusters.
With that I just tried to render 300 million voxels, which also worked, until.... I tried to look at all of them at once at which point the app froze and the driver reset. Cheesy

EDIT2: (25.09.) Implemented "tight fit" quad point sprites. Saves a lot of unnecessary ray/aabb intersections in the fragment shader:

(the yellow transparent quads are the sprites which generate fragments that are ultimately used to do a ray/aabb intersection test in the fragment shader).
Offline Roquen

JGO Kernel


Medals: 518



« Reply #6124 - Posted 2018-09-23 20:09:26 »

Haven't looked at paper yet.  Saw this note from IQ: https://twitter.com/iquilezles/status/1042873159605608451
Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6125 - Posted 2018-09-23 20:50:04 »

Yes Íñigo, you are right, that paper is riddled with errors... Smiley
Offline EgonOlsen
« Reply #6126 - Posted 2018-09-27 13:10:11 »

A few weeks ago, I've added a Javascript backend to my Commodore BASIC V2 cross compiler (https://github.com/EgonOlsen71/basicv2), so that it can not only compile to native 6502 machine language but to Javascript as well.
To render the output in the browser, I've added a C64 screen like console output today. It's far from perfect, but it supports simple PRINT output from the compiled program as well as some control codes for colors and such.

I've used it to compile this mandelbrot program:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
5 PRINT CHR$(147)
7 TI$="000000"
8 DIMX$(16),Z$(11),V,U,A,B,I,R,H,A$,E
10 X1=38:Y1=22:E=15:V=48:FORX=.TOE+1:X$(X)=CHR$(V-X):NEXT:I1=-1:I2=1:R1=-2:R2=1
30 H=(R2-R1)/X1:S2=(I2-I1)/Y1:YH=Y1/2
60 FORY=.TOYH:I=I1+Y*S2:R=R1:A$="":FORX=.TOX1:V=R:U=I
110 FORN=.TOE:A=V*V:B=U*U:IFA+B<=4THENU=U*V*2+I:V=A-B+R:NEXT
120 A$=A$+X$(N):R=R+H:NEXTX:PRINTA$:Z$(YH-Y)=A$:NEXT
130 FORY=1TOYH:PRINTZ$(Y):NEXT
10000 PRINT"TIME: ";TI$;


into this: https://jpct.de/js/index.html

and this prime number generator:

1  
2  
3  
4  
5  
6  
10 W=500:DIM F(500):P=1:A=3
20 PRINTA:F(P)=A:P=P+1:IF P>W THEN STOP
30 A=A+2:X=1
40 S=A/F(X):IF S=INT(S) GOTO 30
50 X=X+1:IF X<P AND F(X)*F(X)<=A GOTO 40
60 GOTO 20


into this: https://jpct.de/js/index2.html

The purpose of all this is...I've no idea, I guess I did it for the lulz.

Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6127 - Posted 2018-09-29 16:17:42 »

Played with water today:



<a href="http://www.youtube.com/v/EgSzL17-rgU?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/EgSzL17-rgU?version=3&amp;hl=en_US&amp;start=</a>
Offline SkyAphid
« Reply #6128 - Posted 2018-09-30 22:11:24 »

Played with water today:
snip

Kai is out here putting Minecraft to shame with a nonchalant side-project lol

it just werks
Offline princec

« JGO Spiffy Duke »


Medals: 1060
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #6129 - Posted 2018-10-01 08:47:42 »

It's scarily competent and I'm worried it's even putting Dan's state-of-the-art Voxoid engine to shame! Surely there's gotta be a catch somewhere?

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6130 - Posted 2018-10-01 09:13:36 »

Albeit being a side-project, till now I've invested a rather significant amount of spare time into it. However, 80% of the time was discovering papers/articles/blog posts, reading them, re-reading them, finding more articles and reading those. Then another 20% implementing a bit of it.
The last couple of weeks, computer graphics became a synonym for "reading papers" and trying them out. I've accumulated a rather large amount of tiny demos evaluating different technologies and comparing them with regards to performance and the TODO list of techniques applicable to this cube world rendering which I need to evaluate is growing rather than shrinking.
Just yesterday I was researching occlusion culling and found this excellent blog: https://interplayoflight.wordpress.com/2017/11/15/experiments-in-gpu-based-occlusion-culling/ which itself contains a dozen more links to articles/presentations to read and watch.

The catch is that I surely will never get this to a playable state. It's a tech demo to satisfy my need to stay up-to-date and play with CG techniques. So I hugely respect and admire you guys for building and releasing actual games. Smiley
Offline princec

« JGO Spiffy Duke »


Medals: 1060
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #6131 - Posted 2018-10-01 10:13:45 »

Well that's the funny thing, only last night we were lamenting that we've spent a whole year (albeit very part-time) building a voxel rendering engine in Java - and it does look absolutely marvellous, make no mistake - but it's really complex and really compute intensive both on the GPU and CPU, and at the end of the day we can only just render a 4096x4096x256 voxel scene at 60fps on the latest hardware. Admittedly it's bump mapped, has arbitrary lighting and shadows, transparency capable, with a particle engine and has fancy water too, but it suffers currently from being a static scene - that is the voxels themselves are not easily modifiable once they're ready to render.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6132 - Posted 2018-10-01 10:30:10 »

To me it sounds that you actually do not have much to lament about. I mean, having all those fatures in your engine is great and seems a rather huge achievement to me. Also please note that my little project is not an engine. It is 700 lines of Java code in a single source file with a handful of GLSL shaders and nowhere near to be used by or useful to actual games/projects. The world size, camera settings and noise parameters are just magic numbers hardcoded somwhere in a method and the flexibility of that is absolutely zero.
Developing an actual *engine* with a usable interface and cramming all the features you mentioned into it is a whole other story.
That's probably where the most effort for you was going into. You would be just as capable of build a simple small demo in a very short time as I am if it wasn't for the aspect of: supporting a content creation pipeline, providing tooling/previews for artists, longevity, maintainability, reliability, flexibility that an engine usually brings about.
Offline ral0r2
« Reply #6133 - Posted 2018-10-01 19:10:18 »

Today I created a boomerang sprite:



also created a shurikan, hammer and potion icons:







Looks like this ingame:

Click to Play
Offline LiquidNitrogen
« Reply #6134 - Posted 2018-10-01 21:00:04 »

Got back into programming again after having no power all winter. Nearly finished with my terrain rendering.



Offline cylab

JGO Kernel


Medals: 188



« Reply #6135 - Posted 2018-10-02 07:12:54 »

Well that's the funny thing, only last night we were lamenting that we've spent a whole year (albeit very part-time) building a voxel rendering engine (...)
Well, look at Atomontage - the guy basically did that at least the last 10 years... so one year is probalby not so bad Wink

Mathias - I Know What [you] Did Last Summer!
Offline cylab

JGO Kernel


Medals: 188



« Reply #6136 - Posted 2018-10-02 07:15:29 »

Today I created a boomerang sprite (...)
Looks like this ingame (...)
Looks good, but make it fly in a curve - it's a boomerang  Tongue Wink

Mathias - I Know What [you] Did Last Summer!
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #6137 - Posted 2018-10-02 08:28:20 »

Just yesterday I was researching occlusion culling and found this excellent blog: https://interplayoflight.wordpress.com/2017/11/15/experiments-in-gpu-based-occlusion-culling/ which itself contains a dozen more links to articles/presentations to read and watch.

I also found this some time ago after I implemented GPU based occlusion culling, which I think I shared here (https://www.youtube.com/watch?v=383EKvaU2vE). Very interesting read, his blog Smiley

Nice to hear that your code is totally hacked sometimes, while your projects certainly don't look like it is.
Offline ral0r2
« Reply #6138 - Posted 2018-10-02 08:50:56 »

Today I created a boomerang sprite (...)
Looks like this ingame (...)
Looks good, but make it fly in a curve - it's a boomerang  Tongue Wink

Appreciated Cheesy ! I'll keep you updated Tongue
Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6139 - Posted 2018-10-02 18:49:27 »

Began adding Hierarchical Z for occlusion culling. First was creating the Hi-Z mipchain (first 5 levels):
Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6140 - Posted 2018-10-03 08:36:35 »

There was one other issue with the "render point-sprite quad and ray/box-intersect the resulting fragments": Numerical stability when cubes are far away. The intersection code from the paper uses a ray/plane intersection test and determines whether the point of intersection lies within any of the possible three sides of the cube visible to the ray.
When rendering many cubes beneath each other, it is sometimes possible that the intersection test will determine that the top side of the cube was hit (giving a normal color of green in the below images) whereas the adjacent pixel is determined to have hit the front or left/right side of the cube (giving a red or blue color). This is effectively aliasing due to the low framebuffer/pixel resolution at far distances. But worse, sometimes the ray even went straight through the cube without a hit being detected for either side!
Although the effect is exaggerated when using those high contrast colors and diminishes when actually shading the cubes, this error became severely apparent when rendering depth values for occlusion culling. It is unacceptable for a ray to go through a cube and hit another cube hundred meters behind it because that higher maximum Z value will propagate through the HiZ mip chain and destroy any occlusion benefits (because no occlusion will be detected for big occluded objects, which use a high mip level to sample depth values from).
To counteract this, on voxel creation I gave each voxel a bitflag (as the w component in the voxel's GLSL u16vec4 vertex attribute) saying which of its neighbors actually exist. This information is then used in the ray/box intersection test to determine whether the ray could actually have hit that side of the box (it couldn't when there is an adjacent box at this side), in addition with an epsilon value depending on the distance between camera and voxel center effectively giving a margin around each possible side of the cube hit by the ray, so that no ray will go through a voxel anymore and proper depth values will be preserved.
Image without and with epsilon and side-flag correction:
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #6141 - Posted 2018-10-04 08:40:18 »

You are using the last frame's depth information for your high-z buffer, do you?
Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6142 - Posted 2018-10-04 09:42:07 »

No, there's no temporal coherence and depth reprojection stuff in that right now. Building the Hi-Z buffer every frame for the nearest occluders. Figuring out the nearest visible occluders (using the BVH tree for frustum culling and to find the k-nearest neighbors around the player), rendering them and building the mip chain takes roughly 200µs. so right now is absolutely okay for me to do it every frame.
Offline 65K
« Reply #6143 - Posted 2018-10-06 10:17:45 »

Coded a BSP based dungeon generator for Lethal Running:
https://github.com/voodoosoft/gameroots-mapgen

Lethal Running - a RPG about a deadly game show held in a futuristic dystopian society.
Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6144 - Posted 2018-10-06 15:40:06 »

Continued the voxel ray tracing experiment with trying stackless (rope-based) kd-tree traversal with SAH split heuristic on it - I had this around for a few months just not used for voxels. This is waaay faster than BVH with Morton Code sorting, though I haven't tried an "Extended Morton Code" algorithm which alters the amount of bits allocated for each dimension.
Both the BVH and the kd-tree traversal now produce the exact same image, but when the BVH one takes 1902µs. the kd-tree one took 1035µs. Apparently, the increased bandwidth for the additional 6 int16_t's (for the rope node indices) is still less than the reduced amount of memory fetches due to not having to backtrack to ancestor nodes anymore.
But the killer argument in favor of stackless (rope-based) traversal is: No need for a ray-restart after the primary hit! Normally, whenever starting a new ray (such as a secondary ray) at the point of the primary ray hit, a full tree traversal has to be done to first figure out where the ray actually starts. Storing the 32-bit stack of the primary ray in the BVH traversal is useless here, since the bits are specific to the path the ray took previously and won't help with avoiding ray-restart.
This is not so with rope-based stackless traversal, where there is no stack and the algorithm can traverse the tree at any given point in any direction without starting from the root. My plan thus is the following: Rasterize the voxels with point sprite quads (is by far the fastest way to get primary ray hits) and when rasterizing each voxel, write to the G-buffer the node index (uint16_t) in the kd-tree containing that voxel. This information is available when building the kd-tree from the voxels list and will just be used as an additional vertex attribute of the voxel GL_POINTS. Then when shooting a secondary-ray to compute reflection/refraction for e.g. water and also when sampling irradiance from each voxel, we read the node index as flat attribute in the fragment shader (or as a voxel attribute in the compute shader) and start right at that node when shooting the secondary ray! No need to traverse down the tree first.
Here is some image of the kd-tree structure and images when I tried to figure out the exit side of a ray in a cube:


EDIT: Some pipeline sketch:
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #6145 - Posted 2018-10-06 18:14:07 »

Very nice! And that lets you rasterize voxels cheaply, evaluate shading only for visible Fragments - supported by tracing secondary rays cheaply because you have the voxel index per Fragment already. Transparents are also not a Problem despite deferred shading, because you can render transparent voxels like solid geometry and in the shading pass trace refraction race against your voxel tree. This is what i did as well with my deferred voxel shading voxel tracing approach, veeery nice Smiley if i did not talk rubbish until now, i have a question: If you trace refraction rays for transparent Fragments into your voxel tree, do you evaluate simple direct lighting where you hit?
Offline Damocles
« Reply #6146 - Posted 2018-10-08 08:37:40 »

Played around yesterday with prototypes on an acrade flight-model.
(Added some simple drones to have something to shoot at)

WebGL demo "Kill"

here a Newtonian flight model, using actual physics (way harder to control, but more interesting in a sense).
WebGL demo "Fly"
Offline Damocles
« Reply #6147 - Posted 2018-10-08 09:07:19 »

Seems you have a bug in your prime number code,
you should edited line 30


1  
2  
3  
4  
5  
6  
7  
8  
10 W=500:DIM F(500):P=1:A=3
20 PRINTA:F(P)=A:P=P+1:IF P>W THEN STOP
24 REM moved X before line 30...
25 X=1
30 A=A+2
40 S=A/F(X):IF S=INT(S) GOTO 30
50 X=X+1:IF X<P AND F(X)*F(X)<=A GOTO 40
60 GOTO 20


Offline KaiHH

JGO Kernel


Medals: 650



« Reply #6148 - Posted 2018-10-08 17:49:10 »

Came to properly implement directional Irradiance Caching with Hemispherical Harmonics (HSH) with 6 H-Basis functions per voxel x side x vertex. The video shows integration of HSH together with some Fresnel approximation to reduce the amount of reflection towards 0° incident angles (with respect to the face normal):
<a href="http://www.youtube.com/v/0P1KSgpxhZw?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/0P1KSgpxhZw?version=3&amp;hl=en_US&amp;start=</a>
How is this useful? To have Fresnel-based reflections of actual incoming directional irradiance. When extending this with chromatic/per-color-channel information, then this can be used to implement reflections on glossy materials.

If you trace refraction rays for transparent Fragments into your voxel tree, do you evaluate simple direct lighting where you hit?
There is currently only soft hemispherical lighting. And all lighting evaluation is currently being done in the off-screen compute shaders which cache irradiance for all voxels. The rendering shader only interpolates the irradiances between the 4 vertices of the hit side.
Offline EgonOlsen
« Reply #6149 - Posted 2018-10-10 08:37:27 »

Seems you have a bug in your prime number code,
you should edited line 30


1  
2  
3  
4  
5  
6  
7  
8  
10 W=500:DIM F(500):P=1:A=3
20 PRINTA:F(P)=A:P=P+1:IF P>W THEN STOP
24 REM moved X before line 30...
25 X=1
30 A=A+2
40 S=A/F(X):IF S=INT(S) GOTO 30
50 X=X+1:IF X<P AND F(X)*F(X)<=A GOTO 40
60 GOTO 20


No, my code is fine. It jumps back to 30 (and resets X) only if it has found a proper divisor (so that A isn't prime). It has to reset X in that case. Your code doesn't work properly, because it doesn't check all the numbers as potential divisors that it should check. It prints out a lot of numbers as prime that actually aren't.

Pages: 1 ... 203 204 [205] 206 207
  ignore  |  Print  
 
 

 
hadezbladez (271 views)
2018-11-16 13:46:03

hadezbladez (148 views)
2018-11-16 13:41:33

hadezbladez (281 views)
2018-11-16 13:35:35

hadezbladez (65 views)
2018-11-16 13:32:03

EgonOlsen (2119 views)
2018-06-10 19:43:48

EgonOlsen (2143 views)
2018-06-10 19:43:44

EgonOlsen (1356 views)
2018-06-10 19:43:20

DesertCoockie (1952 views)
2018-05-13 18:23:11

nelsongames (1595 views)
2018-04-24 18:15:36

nelsongames (2242 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
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!