Futurecraft Forums

A forum dedicated to communication and innovation!
 
HomeCalendarFAQSearchMemberlistUsergroupsRegisterLog in
Welcome, one and all, to the Futurecraft Forums!

Share | 
 

 One more demo

View previous topic View next topic Go down 
AuthorMessage
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: One more demo    Thu Aug 15, 2013 4:34 am

https://www.shadertoy.com/view/4dfGzs

Raytraced voxels using procedural noise, all of it in realtime. This particular one has high coherency by doing a fixed number of steps and no tree traversal. Surprisingly efficient here.

Also featured is a sweet edge detection filter, and yes, we can use it.
Back to top Go down
View user profile
Laserbilly
Infantry
Infantry
avatar

Posts : 584
Join date : 2012-04-19

PostSubject: Re: One more demo    Thu Aug 15, 2013 8:40 am

I don't know what any of that means. How happy/excited are you about it?
Back to top Go down
View user profile
Tau
Infantry
Infantry
avatar

Posts : 517
Join date : 2012-01-16
Age : 17
Location : Ancapistan

PostSubject: Re: One more demo    Thu Aug 15, 2013 10:42 am

I (think I) understood most of it, and it sounds really nifty.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: One more demo    Thu Aug 15, 2013 2:19 pm

Laserbilly wrote:
I don't know what any of that means. How happy/excited are you about it?
The algorithm is a bit too basic for us to use as-is, but it is cool to see the ray-tracing method in action.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: One more demo    Thu Aug 15, 2013 5:20 pm

I should probably elaborate on part of that. GPU processing power dwarfs CPUs by orders of magnitude, but it also has some very strict rules for how it is to be used. If you don't follow these rules, you lose the ability to process things in parallel and the performance drops massively. Particularly branching, which is where depending on a condition the program can execute two different paths of instructions. Threads running this code are in a big block with other threads, and they all have to execute the same code. If half of them branch true and the other half branch false, the GPU will stall all the false branch threads, and then go back and stall the true branch threads until both code paths join back up.

In ray tracing, this can get particularly bad, because depending on which block you are in, you might want to stay where you are, or traverse to another block, or in the case of SVOs, travel up or down the tree, and the ray adjacent to you might be in a different voxel and follow a completely different path.

In the demo I linked, it gets around the concurrency issue by making every ray travel 128 steps regardless of whether it hits anything, and it check to see if it hits every time. Rays that did hit will stall, but there is no code executed in that branch, so the GPU can immediately switch to the branch that has traversing.

It's a nice trick, but it wouldn't scale to larger scenes with lots of empty space to traverse. For that you need acceleration structures, which I have mentioned a few times before. Essentially, an acceleration structure is meta data in the voxel structure which the ray can interpret to figure out how far it can safely step without hitting anything. Since it's not normally view-dependent, it tends to be conservative estimations, such as the distance in any direction from a voxel to the nearest solid object.

With the heightmap variety I use, the acceleration structure is a lower resolution version of the heightmap, where each texel represents the max height for that area. As long as the ray stays above this on the low resolution map, it doesn't have to check the higher resolution map for collisions. I'm still working out whether an acceleration structure will be necessary for the SVO model. Since the geometry will be in small pieces scattered about, there won't be really large empty spaces, so maybe not.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: One more demo    Fri Aug 16, 2013 2:10 pm

Btw, this iq guy, actual name is Iñigo Quilez, is one of the smartest guys I have ever come across.  If you are at all interested in procedural generation or shader techniques, you should check out his articles http://iquilezles.org/www/.

There's also some really mindblowing demos.  I'll save you some time and link the coolest one.
http://pouet.net/prod.php?which=52938
It's pretty impressive on its own, but when you realize the entire file is <4KB in size it becomes ridiculous.

*edit*
Dammit, it's not working on my PC. It did on my last OS. Not cool.
Back to top Go down
View user profile
fr0stbyte124
Super Developrator
Super Developrator
avatar

Posts : 1835
Join date : 2011-10-13

PostSubject: Re: One more demo    Mon Aug 19, 2013 12:08 pm

Starting to make some headway decyphering the tron-cube looking demo. It's really quite clever with its use of vectors. The most complicated bits are actually only operating on one component at a time, depending on which is the primary axis, but because the math operates on the whole vector, it doesn't care which one is the primary.

For instance, the cool edge detecting part is actually sampling a + around the active face. It has a vector input which looks like (0,-1,0) representing which face the ray hit, and from that it would sample the +X, -X, +Z, -Z directions simply by rearranging the components. I'm still working through the ray-tracing logic, but it is based on the same principle.

There's also a fake ambient occlusion in here, which is equivalent to smooth lighting in minecraft. This one is based on a variation of the edge detection code, only it distinguishes inner vs outer edges.

Aside from the incompatible raycasting procedure, this code is quite good, and would be easy to take advantage of. However, the real challenge will come from memory access. This demo uses a 3d noise function, which can be accessed randomly from anywhere. When we read map data, it will be from textures, either from a height field or an oct-tree, so we need to deal with boundaries and passing between separated chunks. Easiest would be making each chunk 30x30 and having a ring of padding around the structure, but this throws everything else off. Alternatively, if there was some efficient way to hop between patches in virtual memory, it would liberate the raytracer considerably, but if the rays don't stay together, the texture cache that all the memory access relies on could get thrashed and destroy the performance.

There's a lot to plan out. Raytraced shadows would be nice as well (especially with a new cone mapping system I am considering), but I don't know if it will be possible so long as the height field and oct-tree structures are done in separate passes.
Back to top Go down
View user profile
Sponsored content




PostSubject: Re: One more demo    

Back to top Go down
 
One more demo
View previous topic View next topic Back to top 
Page 1 of 1
 Similar topics
-
» Should Nintendo Release A Splatoon Demo And Advertise The Heck Out of It?
» Moto Heroz (NL Racers)
» FE7 Batta Mode DEMO
» Super Smash Bros. for 3DS demo first impressions
» Nintendo Direct - North American and European News (21/06/12)

Permissions in this forum:You cannot reply to topics in this forum
Futurecraft Forums :: General Area :: Off-Topic Area-
Jump to: