Sounds good!
Yeah, the PlayStation resolution is not too bad and would look like and interesting game, specially with a crt/ntsc shader applied to the frame.
Honestly I've always wanted to make something Minecraft style!
The fake depth buffer also sounds good.
Nah, it's not for yet another Minecraft clone. Cubes are boring and ugly.
It might not look like much, as I'm still testing with cubes, but each one you see is actually now a proper 16x16x16 voxel model, that you could make any shape you like - for example, remember my old Sopwith biplane?
Just having some troublesome rounding issues at the moment, but it's getting there...
I've managed to fake a depth buffer in DX11, so now separate actives can be placed "inside" the voxel world, which is quite a significant change:
The trick is that instead of using the red, green and blue components to store the colour of the voxel, I just use the red component to define a palette index, and then use the green and blue components to store lighting and depth information. And then each object samples the background, reading the blue component to decide whether it's in front of or behind it. And finally, another shader samples the red component and uses it to look up an RGB colour from a palettte image to display.
Very impressive, every time I check you're making amazing progress.
Merry Christmas!
Just thought I'd share the progress I've made on my Voxel World shader.
I decided to try making a more complex scene (based on an image found online) as a way to test the shader, and decide what works and what doesn't, and what needs adding. I know I could fix some things with it, or add more detail, but I think it's served its purpose now.
In a nutshell:
* Happy with performance.
* Not happy with lighting - will change to using a point light source instead of directional lighting.
* Desperately needed a way to flip/mirror voxel blocks, so have now added that.
Looks awesome! I agree with the Minecraft thing.Originally Posted by MuddyMole
However, the way minecraft only shows you surfaces you actually need to see is awesome for saving resources.
Excellent work so far!
As far as lighting goes. Maybe to save resources just have a .png in front of the player which size is controlled by floating Actives around the player.
I.E. Left Active controls the stretch of the .png out to whatever it collides with. Right active does the same off to the right of the player's view. Same with up and down / Directional.
If the active comes in contact with an object it forces the X of the active inwards squeezing the .png to make the light look like it is reflecting. Even though, it's obviously not true light!
Example file
ThanksI like the vignetting for a kind of flashlight effect - especially in horror games.
The lighting system actually has a pretty negligible cost in terms of performance. Basically, the shader relies heavily on one complex function which gets the contents of a point in 3D space. The lighting system is mostly just calling that function once for each space neighbouring a solid voxel that a ray hits (so 6 times if we just consider orthogonally adjacent spaces) in order to calculate a surface normal. However, the same function gets called once for each space between the camera and that first solid voxel that the ray hits, and that distance is generally going to be much, much greater than 6, and potentially as much as 1000 (or whatever the maximum draw distance is). The cost of the fog/darkness effect is essentially zero, since it's just using information that we needed to calculate anyway.
The real issue is that unlike outdoor environments, which often only have one lightsource (the sun), indoor environments usually have many (that test scene has rows of lights in both the ceiling and floor). Baking the light into the model is the obvious solution, and that's mostly fine (apart from making it even more difficult to create maps), except for when there are glowing objects such as lamps - it looks very wrong for them to be affected by the darkness/fog, the same as any other material.
I think I need to replace the directional light with a point light (ie. instead of using a fixed light vector, I'd use the vector from a fixed point to each voxel). It could still be used like a directional light if placed far away from the scene, or it could be always placed at the player's location for more of a torchlight effect.
And then I'm thinking that the 256 colour palette could be divided into sections with different properties - for example:
0: transparent
1-50: matte surfaces (no specular highlights)
51-150: standard surfaces
151-200: glossy sufaces (more intense specular highlights)
200-245: illuminated surfaces (effect of darkness varies continuously, from 200:"almost normal", to 245:"almost no effect").
246-255: emissive materials (not affected by darkness at all)
The real challenge will be "inserting" models using separate actives into the same scene. The demo above with the smiley face shows that the depth system should work, but the objects still need to be correctly positioned, scaled, rotated and illuminated to match everything else (or at least positioned and scaled in the case of a billboarded 2D sprite) - that's going to involve a lot of complicated maths, much of which needs to be done outside the shader, using CF2.5 events...
Who wants a little maths lesson?
The shader for the tile-based voxel environment is pretty much finished now, so it's time to move on to the next part of the engine - other objects that can be placed within the environment.
Let's start with 2D "billboard" sprites - and just while we figure out the maths, we'll work in two-dimensions only.
So, first of all we need a vector pointing in the direction the camera is facing:
camDirX = cos(cameraAngle)
camDirY = 0 - sin(cameraAngle)
(right now, that's a "unit vector", with a length of 1)
Next we need a vector (purple) perpendicular to that, some distance in front of the camera, and with a length equal to the width of the viewing window. If if we were to draw lines from each end of this vector to the camera, the area inside would be our field of vision.
The distance of this vector from the camera (ie. the length of the orange vector) defines how wide the field of vision is - the shorter the distance, the wider the field of vision (we just pick a value that looks "right").
Next, let's calculate the vector perpendicular to the camera direction vector. To do this, we simply swap the X and Y components, inverting one of them. Note that there are two possibilities - either 90 degrees to the left or 90 degrees to the right - so we'll pick the vector to the right.
perpCamDirX = -1 * camDirY
perpCamDirY = camDirX
Now, we need the vector from the camera to the sprite (white).
camToSprX = spritePosX - cameraPosX
camToSprY = spritePosY - cameraPosY
Next comes the clever part. Instead of using the sprite's position relative to the X and Y axis, we can find its position relative to the camera direction (orange) and the vector perpendicular to that (blue). We can find the length of the light purple vector by calculating the "dot product" of the sprite's position vector and the camera direction vector:
camToSprA = (camToSprX * camDirX ) + (camToSprY * camDirY)
Note that if this value is negative, it means the sprite is behind the camera, and will therefore not be visible.
And we can find the length of the light green vector by calculating the dot product of the sprite's position vector and the vector perpendicular to the camera direction:
camToSprB = (camToSprX * perpCamDirX ) + (camToSprY * perpCamDirY)
To get the gradient of the line from the camera to the sprite (white), we can divide the second of those values (green) by the first (purple).
gradSpr = camToSprB / camToSprA
Next, we need to find the gradient of a line from the camera to the right edge of the field of vision (red). We could do the same as before, but there's an easier way. We know that the length of the orange vector is simply our cameraDistance variable. We also know that the total length of the purple vector is equal to the width of the viewing window, so if we halve that we get the length of vector to the right of the camera direction. Divide one by the other, and we have the gradient of the red line:
gradView = (viewWidth / 2) / cameraDistance
If we divide gradSpr by gradView, we get the position of the horizontal position of the sprite relative to the centre of the viewing window. A value of 0 means the sprite is in the centre of the view. A value of +1 means the sprite is at the right edge of the view. A value of -1 means the sprite is at the left edge of the view. A value outside the range -1 to +1 means the sprite is outside the field of view.
If we add 1 and then divide the result by 2, we convert that to a value in the range 0 to 1, and if we multiply this value by the width of the viewing window, we get the horizontal position of the sprite on screen, in pixels (light mauve).
It's basically the same for the vertical position, although things do start to get complicated if we add another degree of freedom for the camera (roll)... And then there's the small matter of scaling the sprite with distance...
Damn. This is very impressive.
Posting Permissions
Reply With Quote
