Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Jul 2013
Offline Last Active Oct 20 2016 10:52 AM

Posts I've Made

In Topic: Placing Things in a (Kinda) Voxel World

22 July 2015 - 11:07 AM

The way I handle this in my editor is to


1)    Create a copy of the object that is to be inserted and make it 60 to 70 percent transparent


2)    Insert this object a set distance away from the camera (using the look/target vector)


3)    Set all mouse movement to project the objects move in a single plane - The plane is determined by the camera's horizontal angle.. IE if the camera's target vector is greater than 45 degrees away from the xy plane vector, then the movement is in the xy plane.


4)    After drawing the transparent version of the object, draw the object twice more using a stenciling mechanism to only draw the outline of the object - make this outline some solid color. On the second draw turn off depth checking so that the outline is always drawn.


5)    Change the overall object color to transparent red if the user cannot insert the object at the current location.


In essence, you use whatever object you are trying to insert as an "object brush" that moves in a single plane following the users mouse movements. You can then set up a key (or a couple keys) to allow the user to change the plane of movement.


The outline of the "brush" will always be shown in the editor even when behind other stuff so the user is not confused, and you can change the color to red (or whatever color) to indicate that the object is not insert-able at its current location. When the user clicks in a valid location, you create an object in that spot and snap the object's position to whatever grid you want to use.

What kid of editor did you make? When I was writing the editor for my engine, I just used the standard 3 arrows in the XYZ and did the math for that. IMO thats the best solution, but I feel like that wouldn't be immersive enough to give to a player.

In Topic: Placing Things in a (Kinda) Voxel World

20 July 2015 - 07:39 AM

What about using colors in an offscreen buffer to index specific locations that objects can be placed at? This is a common way to handle it.




This gives you 24 bits of ID - 16777216 IDs, though we'd reserve one ID (the largest - that is, the color (255, 255, 255)) to mean "no ID"/"invalid ID"/"nothing is located under your mouse".


For example, the player is standing at a specific location, looking in a specific direction. He's holding a specific object (FooObject), which has certain behavior. FooObjects can only be placed ontop of grass terrain, but can also be placed in air, as long as it's immediately connected to a nearby cliff. From where the player is standing, there are ~10 blocks near him. Only 4 of them are grass blocks, but two of them already have objects on them. There are also three nearby empty spaces connected to the cliff, so 5 potential locations where the FooObject can be attached to.


In memory, create 5 potential "AttachmentPoints". Give each one an ID, starting at zero and counting up.

Create an off-screen buffer of some resolution or other (half the screen resolution is probably fine, but if it seems too imprecise, make it the same as the screen's resolution).


Clear the off-screen buffer to all white (255, 255, 255). For each one of your attachment points, draw those objects using the index {0, 1, 2, 3, ...} reinterpreted as a color {(0,0,1), (0,0,2), (0,0,3), ...}.


Then, using the mouse's location, get the (offscreen/invisible) pixel under the mouse, and you now have the ID of the object the player is clicking on.


This even lets you give different IDs to different sides of the same object - because attaching a block to the top of a cube is different than attaching a block to its side, and you need to know which side the player clicked on.


Because certain objects can "block" the player's view of a attachment point (think of a tree trunk halfway obscuring a placement block - you want the player to be able to place on the visible part of the block, but not be able to place "through" the tree trunk), you need some way to obscure those parts of the off-screen buffer from being colored.


You can do this the simple but slow way of redrawing the entire world to the off-screen buffer, but redrawing it as solid white to "erase" the part of the attachment points that are visually blocked, but instead of drawing every object a second time, you can just reuse the depth buffer of your regular screen rendering - either by copying the depthbuffer into your offscreen buffer, or by making your offscreen buffer be drawn into at the same time as your regular buffer is being drawn into, since shaders can output to more than one buffer at the same time.


Something like this:

#version 330

uniform sampler2D DiffuseMap;

in vec2 fDiffuseCoord;
in vec4 fColoration;
in uvec4 fObjectID;

//Output to the frame buffers:
out vec4 VisibleScreen;
out uvec4 OffscreenIDBuffer;

void main()
    vec4 diffuseFrag = texture2D(DiffuseMap, fDiffuseCoord);

    VisibleScreen = (diffuseFrag * fColoration);
    OffscreenIDBuffer = fObjectID;

Also, if you are targeting OpenGL 3.0 or higher, you could disable alpha blending for only the offscreen-buffer ( glDisablei(GL_BLEND, offscreenBuffer) ), giving you all four bytes for use with IDs - which is nice if you want to more permanently give IDs to objects - But because there shouldn't be more than a few dozen objects within click-range of the player, so you can also just assign IDs dynamically and re-use them as needed.

I am using color picking temporarily in my engine for the editor portion, but I'm going to switch to using rays in the future. Color picking is kinda slow, but it does work well. Since I'm using voxels though, its kinda not needed because I can just construct a simple tree and retrace it against that, which would probably be faster in the long run. Because color picking needs objects, I think it would have a hard time figuring out where to place something that was in the air because there won't be any objects there.



Just an idea that popped into my head, so I don't know if it'll work, but maybe?
If I got your description right, you got a world of voxel-ish cells where you snap your objects.
My idea was to use the scroll wheel during object placement to control a cylinder around the player. The scrolling would control the radius of the cylider. Then you should be able to use the cameras forward vector to pick the 'voxel' on the wall of the cylinder using a bit of simple trig, no?


Servant's aproach seemed more sophisticated though, and probably more tested and true. Just thought I'd mention the idea. smile.png

I think thats what I'm going with. I decided to just use the projected ray from the player's camera with a certain length and then change that length with the scroll wheel. Its probably the best and simplest option.

In Topic: Cascaded Shadow Maps Look Bad

10 February 2015 - 02:51 PM


No, thats what the crop matrix does. It will make the scene bigger or smaller so that the bounding box always fits onto the shadow map.

Then you have a different crop matrix for each cascade…yes?

as you both assumed that I was taking into account the scene geometry, which I am not.

I’ve made no assumptions—I’ve never heard of using a crop matrix for cascaded shadows, and don’t understand the approach you are taking enough to make any assumptions.
What I described in my last post isn’t based on assumptions about what you are doing, it’s just the standard way it is done in the industry.

From the sounds of it, it is also more efficient and more straightforward than what you are doing, and will definitely eliminate the problem you have with zaggies, so if your current approach isn’t working I’d suggest just dropping it and starting over using the standard approach. If it has one advantage at all, it’s that by being the standard approach you can certainly find more information on/help with it.

L. Spiro


I was under the impression that the way I've been doing it is the standard way. I've looked at 9-10 different references and none of them do it the way you just described. If you have a reference, I'll take a look at it.

In Topic: Cascaded Shadow Maps Look Bad

09 February 2015 - 07:57 PM

But you're creating a new orthographic projection matrix for each shadow map/slice right? You would need to because as you work through the slices, they get progressively bigger meaning you'll need to adjust your width and height to encompass them.

No, thats what the crop matrix does. It will make the scene bigger or smaller so that the bounding box always fits onto the shadow map.

In Topic: Cascaded Shadow Maps Look Bad

09 February 2015 - 07:47 PM

The code you sent initially doesn't seem to have any reference to the camera frustum slices, it looks like the orthographic projection matrix width and height is created based on a frustum with near 0 and far 1000 - unless I'm missing something?

The frustum slices are inputed with the distances[] array. The orthographic projection doesn't change from the frustum splits, the crop matrix handles all of that.