Jump to content

  • Log In with Google      Sign In   
  • Create Account


Octree-based voxel lighting system


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
15 replies to this topic

#1 Kiel368   Members   -  Reputation: 215

Like
0Likes
Like

Posted 05 October 2013 - 06:39 AM

Hi!
I'm creating a voxel terrain engine for my game in Unity, but I don't know, what's the best way to implement lighting. I wanted to write it as it is in Minecraft - CPU calculating light for each vertex and then shader multiplying output color by this value, but I've got octrees implemented, which means that one faces are big and other ones are small, which is a major issue when creating per-vertex lighting. I wouldn't like to have to divide bigger faces to get the lighting resolution I want, because then octree rendering optimizations lose their sense. Is there a way to overcome it? Using unity lighting would mean that I have to buy Unity Pro (which is too expensive for me) to make shadows and deffered rendering and I wouldn't be able to tell how dark it is in a certain place on the map. And of course real-time lighting would mean a major performance drop, which I cannot afford. Please help if you can. confused.png



Sponsor:

#2 Scouting Ninja   Members   -  Reputation: 636

Like
0Likes
Like

Posted 05 October 2013 - 10:32 AM

Instead of applying the light to each face of a object you should apply the light to the pixels of the textures by using a per pixel shader.

Unity uses DirectX so you will need to use HLSL.



#3 Kiel368   Members   -  Reputation: 215

Like
0Likes
Like

Posted 06 October 2013 - 07:06 AM

Is there a way to do this once and not every frame? (I don't know, a lightmap or sth.)



#4 Shane C   Crossbones+   -  Reputation: 1185

Like
2Likes
Like

Posted 06 October 2013 - 07:11 AM

Is there a way to do this once and not every frame? (I don't know, a lightmap or sth.)


How come? Per-pixel lighting is ran on the graphics card and the graphics card is a parallel device which means it's fast at it.

#5 conq   Members   -  Reputation: 337

Like
2Likes
Like

Posted 06 October 2013 - 11:17 AM

*EDIT* Oh wow, didn't read the follow up post. *EDIT*

 

Don't pre-optimize things like lighting, make a demo for it and see how good your implementation is first.


Edited by conq, 06 October 2013 - 12:10 PM.


#6 Kiel368   Members   -  Reputation: 215

Like
0Likes
Like

Posted 06 October 2013 - 12:54 PM

I tried directional light, but it makes a lot of consrast between a top and a side face of a block, when I set ambient lighting to light-gray it's okay, but then caves are not dark. I use shadows to darken caves otherwise the top faces in the cave are exacly the same light as ones on the surface. So, how to make surface well lit and caves dark?



#7 Kiel368   Members   -  Reputation: 215

Like
-3Likes
Like

Posted 07 October 2013 - 11:07 AM

HEY, PLEASE! CAN ANYONE HELP ME?



#8 Kaptein   Prime Members   -  Reputation: 2059

Like
2Likes
Like

Posted 08 October 2013 - 08:53 AM

It's one of those "if you have to ask ...", but...

I'm creating such an engine right now, there are a few options for you:

 

1. use shadow maps - probably ok - some minecraft mods use this, and it's neither good nor bad

unfortunately shadow maps requires you to run a "shadow" rendering scene pass, which means you halve your fps for nothing at all

when you could instead be using the second pass to render water reflections for which there is no alternative but to actually render everything at plane reflected position/angle

(this one is most likely the easiest way for you to get shadows, so if you just want to get from A to B fast - consider shadow maps)

 

2. use "vertex lighting," meaning you append data to your vertex struct (im assuming you at least have this)

and using this additional data you can add shadows, brightness & lighting to each vertex on the field

the good part is that you can use each individual channel as part of a composite light value, let's say R = shadow, G = brightness, B = corner shadow / fake ao

then you can make up simple rules to achieve realtime daylight and blabla, and since corner shadow is its own parameter you can ramp it so that its a very thin black line

 

3. deferred lighting - won't scale at all, takes time to implement, and means you have to spend lots of time isolating chunks of your world just to keep the light count down

in a voxel world you with actual players you typically have a few thousand lights, sometimes all visible

i should know, i have testers who routinely push the boundries (and being the yes man that i am, routinely work out ways to make things ever faster)

 

yes, im probably telling you directly to use vertex lighting

but maybe not.. its up to you what kind of scale you want to achieve.. i dont even know what kind of game you are making :S

its hard to tell you for sure what you should do

 

is your world 3D? as in not a glorified plane like every other game in existence


Edited by Kaptein, 08 October 2013 - 08:55 AM.


#9 Kiel368   Members   -  Reputation: 215

Like
0Likes
Like

Posted 08 October 2013 - 01:24 PM

Yes, my world is 3D! :-)

It's a voxel terrain engine  (as for now, later i'm gonna create a game using it). It uses octrees instead of clearly homogenous space to conserve memory and remove unseen vertices. Well, vertex lighting is what I intended to do, but the problem is that some faces are bigger and other ones are smaller, so there's no consistent vertex count per any map resolution level, so if we place a light, say, above a 8x8 meters surface, there's no way I can spread lighting across the face with only 4 vertices! :-) I thought about it for a while and found possible solution: the light can be calculated when building chunks per smallest possible voxel (vertex lighting like in Minecraft) and then, instead of subdividing bigger faces (which makes octree optimizations a non-sense), let's programatically create a lightmap texture, using per-smallest-voxel calculated values and map it to bigger faces as TEXCOORD1.

 

Crazy idea, isn't it? smile.pngsmile.pngsmile.png

Is this solution possible or there's sth. I did not think about?



#10 Kaptein   Prime Members   -  Reputation: 2059

Like
2Likes
Like

Posted 08 October 2013 - 05:50 PM

i dont know, it does sound kind of ridicolous to create 3d lightmaps? maybe it works out.. i dont know

honestly, why dont you just subdivide faces where the lighting changes?

just because your actual world data is an octtree doesnt mean your mesh is :P or does it?

 

i thought about it once, i think, but i didnt try it.. and i dont know much about how minecraft does things :P

i hope it works out for you



#11 Kiel368   Members   -  Reputation: 215

Like
0Likes
Like

Posted 09 October 2013 - 07:29 AM

I think it is cheaper to apply additional TEXCOORD than subdividing faces into 6cm (the smallest voxel possible) (or rather n cm) sqares and creating lot's of actually unneeded vertices. Well, we'll see.



#12 HScottH   Members   -  Reputation: 508

Like
1Likes
Like

Posted 03 November 2013 - 01:29 PM

Kiel, this is not a crazy idea at all.

 

I am writing a similar game, and because of my requirement to render huge distances, I have spent a great deal of time on optimization.

 

I was using per-vertex light data, but as you point out this causes many unecessary subdivisions in the meshes; everyplace, such as under a tree, in my world, the large meshes would degrade into 1x1 meshes.

 

For one particular world region, containing 382,000 visible faces, my meshing alorithm was only reducing this to ~250,000 quads. Once I moved my lighting data out of the vertices and into its own texture, that number dropped to 145,000 quads, and my frame rate went up by around 50% (on mid- to high-end hardware, and between 25% and 100% on lower end hardware).

 

I am using 2D, and not 3D textures, and I am packing them so as not to push any more texture memory than is necessary.

 

I'd love to see some screen-shots or otherwise hear about your project. I am doing this purely because I love it :-)



#13 Kiel368   Members   -  Reputation: 215

Like
0Likes
Like

Posted 26 December 2013 - 06:15 PM

HScottH,

 

My project is right now under heavy development, but really early alpha version will be ready soon. Also my website is being created.

 

I have quite a bit of more important work before I come to lighting system, but if I make any screenshots, they will be posted right onto my website as well as the download of the game and the entinre GDD (Game Design Document).

 

If you are interested write a reply here or any kind of message to me and I will supply you with some more information.



#14 dougbinks   Members   -  Reputation: 484

Like
1Likes
Like

Posted 28 December 2013 - 01:36 PM

Funnily enough I've been thinking about the lighting system in my own work recently, and there's some similarities as I'm using an Octree as well.

 

You can probably do decent per-vertex lighting the Minecraft way by subdividing the large voxels. In my own game I subdivide large nodes to the smallest voxel size for nearby regions, and use higher nodes of the branch of the Octree for level of detail in the distance. Hopefully you can see the LODs working in this (debug rendering) video. Using this approach has the advantage of fast vertex generation without seams, using skirts between LOD regions. So if you use this approach and have slow moving  or stationary lights you should be able to do fairly decent lighting which gives you some global illumination like properties.

 

I'd disagree that deferred rendering doesn't scale well - indeed that's it's purpose. Culling can be done via tiles in DX11+ (or equivalent in OpenGL), see Andrew Lauritzen's work, or you can use the stencil buffers. I've been considering using the voxel octree itself to do CPU side culling, but haven't looked into it yet.

 

I'm also considering voxel cone tracing or light propagation volumes, doing the work CPU side using the octree and then uploading the results asynchronously to either a light-map or 3D texture cascade. I've no results or even back of the napkin calculations of feasibility yet, but  will try to blog the results when I do.



#15 larspensjo   Members   -  Reputation: 1526

Like
1Likes
Like

Posted 28 December 2013 - 02:28 PM

Hopefully you can see the LODs working in this (debug rendering) video.

 

I find it difficult to implement a good LOD in a voxel system that have seamless transitions when you change the distance. In your movie clip, there is such a change at 19s.

 

I use a shadow map for my vortex game engine. It is a full deferred shader, enabling me to use lots of lighting sources efficiently. I think this is necessary if you also want to add other lighting effects as well as screen space based algorithms. Vertex lighting could be a problem if you want dynamic shadow effects?

 

unfortunately shadow maps requires you to run a "shadow" rendering scene pass, which means you halve your fps for nothing at all

Agreed, it can be costly. On the one hand, it doesn't have to double your render time as the shadow map is only one of all render operations. On the other hand, you probably have to include geometry not visible to the player (outside of the frustum).

 

Valley_2012-09-30.jpeg


Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

#16 dougbinks   Members   -  Reputation: 484

Like
1Likes
Like

Posted 28 December 2013 - 04:37 PM


I find it difficult to implement a good LOD in a voxel system that have seamless transitions when you change the distance. In your movie clip, there is such a change at 19s.

 

Yes, it's tricky. Eric Lengyel's transvoxel algorithm is one of the best for marching cubes (http://www.terathon.com/voxels/), and Miguel Cepero's Voxel Farm seams are pretty decent http://procworld.blogspot.fr/2013/07/emancipation-from-skirt.html, though I'm not sure what technique he uses as he has dual contour voxels. I use simple skirts for now with the skirt normal adjusted to minimize transition contrast, though I've not had time to cater for certain edge cases such as the one you spotted.

 

The main issue with shadow maps for me is the lack of light propagation in occluded volumes, such as caves. Otherwise they're great.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS