Memamoo
Hi,

I've been experiementing with the UE4 Plugin this weekend, and have a bunch of questions, if that's ok.

First off, the plugin itself seems to be quite good so far. I think alot of my issues are more a lack of knowledge when it comes to VoxelFarm and to a lesser extent, UE4 themselves rather than the Plugin so to speak.

Brief outline of my project setup:

* UE4.15
* UE4 Plugin setup as per documentation
* Using the GreenTerrain example for my terrain
* While learning, I'm doing all the keys/ticks/etc on the Level Blueprint
* Event Tick:
  * Does Set ClipmapviewFocus setup
  * Does Set Block Line Of Sight
  * Does a line trace (vis) in same direction as Block Line Of Sight and displays a debug box
* Mouse Wheel: Scrolls through the available texture material IDs
* X/C/V: Decrease block size X, Y, Z
* shift X/shift C/shift V: Increase block size X, Y, Z
* Left Click: SetBlock with stored material ID (as per mouse wheel), and stored Block Size
* Right Click: SetBlock with Air (0) with stored Block Size
* P: StampMesh at position given by same line trace as above (Scaled by block size). Mesh is the Linear_Stair_StaticMesh

1) Placing/Removing blocks sometimes removes the mesh segment, which if you're standing on it, means you fall through. How should I be handling this?

2) How can I accurately visualise what is going to change? I am drawing a debug box at a point which is roughly where it is being affected, but not exactly. Essentially I'm line tracing along the same vector I am passing to the SetBlockLineOfSite call in Tick.
However, this doesn't take scaling/etc into affect, and while it is a good approximation, I'm assuming there is a much more accurate way of doing it.

3) There seems to be a lack of a way of choosing exact locations to modify? Is there anyway to say I want a block of Size (X, Y, Z) at Position (X, Y, Z) to be Material M?

4) User saves seem intermittent. Is there a way of specifically triggering a save? Or at least determining whether/when all saves are serialised?
Related (maybe): sometimes changes can take a few seconds to be applied. Is there any way to detect this properly?

5) I can't seem to reliably be able to remove blocks that I've just added. Is this because it's not saved properly?
Related: If I stamp a large object (the default stairs mesh scaled up to be quite large), I seem to only be able to change the outer surface back to air. I can't seem to "dig" further into the object.

6) Is there a way to change the rotation of the StampMesh blueprint node? It seems to always stamp in the same orientation

7) How am I supposed to handling buildings with the UE4 plugin? Do I just stamp them with particular materials? Or are they normal models, or ?

8) Is there a foliage example?

9) Stamp doesn't seem to be honouring the material, it's always the white "no-material" material

10) Are there any best practices available for obvious (in hindsight) things to do/avoid/etc?

Sorry for all the questions, especially for any particularly stupid ones [smile]

Thanks again,
- Mark
0 0
voxelfarmtorres
1) We are working on a scene synchronization that swaps in the same frame so there won't be a moment without a proper surface. While this is ready, possible workarounds: a) suspend character physics until the next scene event is ready, which means the world has updated b) set a modification ratio so the character cannot dig under its feet

2) The Block edition interface uses a global snap grid determined by the block size. An upcoming update to the plugin will add means to know where the next block position will be. This is currently known inside the engine, but not exposed to blueprints.

3) If you are working in C++, there are functions you can call to set blocks directly. This is not exposed to blueprints yet. We can provide pointers on how to do this from C++ if this a viable alternative for you.

4) The current plugin (3.0.0.8) uses a lazy save approach that runs on a thread. You can replace this by hooking a different interface for notification callbacks. Your callbacks will be called by the engine to both load and save chunks.

5) When the content was added should not matter. We would like to hear more about this issue.

6) Not at the moment, we intend to use a full transform for the stamp mesh. This is not a difficult change if you are up to modifying the C++ code, we could provide pointers to where the stamping happens. The solution would be to transform the mesh vertices before calling the engine's stamp mesh function.

7) Not sure what you mean by "buildings". The voxel engine does not have the concept of a building, it is all voxels. You could stamp a mesh that is a house, another mesh that looks like a zebra, etc. Or are you referring to the "Prefabs" system?

8) Foliage is not voxelized but instanced as a mesh. You can see how to add instances here: http://www.voxelfarm.com/doc.html?ue-instances

9) This could be a bug. We will double-check.

10) We are in the process of figuring this out. For the moment just be handsome [smile]
0 0
Memamoo
Hi,

Thanks for your reply.

2) I'm happy to do stuff in C++, could you point me in the right direction? Or when you say C++ you mean within VoxelFarm itself (as opposed to code in the plugin I can modify)? If it is possible for me to access this information, can you please give me a place to start?

3, 4, 6) I'm happy to modify what I can, wherever I can. Could you please provide further information/pointers for these three items please?

5) What extra information would you need to look at this? Should I make a simple demonstration project that exhibits the behaviour? Or would a video of me doing (and failing) be easier/better?

7) Sorry, I could have phrased this question better no doubt. Essentially, I'm curious what the best way to go about putting buildings on the terrain is. I can vaguely remember reading something about being a separate layer/class BlockData? that was mentioned somewhere about being good for doing buildings.
Not sure where I saw it in the docs though, and can't check from here, sorry.

I was assuming that while LSystem/Prefabs are used for alot of the big buildings/etc, that they wouldn't be used by the end user building their own building (for example). In that case, I wasn't sure
if it would be better to give them wall/roof/floor materials/etc which they use to build (but would be grid aligned as you mentioned), or allow them to place actual wall/roof/floor models (and not voxelise them).
Does it matter? Are there massive glaring flaws in either?

7b) Is there an example for UE4 using LSystem based buildings? Would like to look in to these further, but after from having a quick look in the docs, haven't spent much time on them.
Or a hint as to how to hook it in?

9) Thanks, please let me know what you find.

Another question I forgot to ask yesterday:
11) Is it possible to determine what voxels will/has been modified: i.e the requested operation will/would remove 10 Grass1, 5 Rock1 Moss, 2 Concrete voxels?
If so, how would I do that? Would this be done with the save/load hooks you mentioned earlier?

Thanks again,
- Mark

0 0
Koniferus
Quote:
6) Is there a way to change the rotation of the StampMesh blueprint node? It seems to always stamp in the same orientation


This has been a big one for me as well. I was unsuccessful in converting it to use a transform in C++ (as I'm a C++ noob)

Not sure if this will help, but here's what I did in the meantime:

For my project, I wanted to dig through terrain as my characters laser projectile blasted into it. I ended up calling the stamp with a sphere mesh and repeated the stamp, changing the location gradually in the direction I was shooting with each iteration, and decrementing a counter to control how deep it digs.
0 0
voxelfarmtorres
2) This is C++ code you can modify in the plugin. To discover the next block's action you must start at the ClipmapView's hitInfo structure. This is a record of type VoxelHitInfo, which contains information about the last ray trace into the voxel world triggered by SetBlockLineOfSight(). The following code computes the origin (in absolute Voxel Farm world coordinates) of the edition box. This is the block currently under the line of sight, which we call the focus block. It is what would be removed if you delete blocks at this location. In this example "view" is a pointer to a CClipmapView instance:

int hlevel, hxc, hyc, hzc;
unpackCellId(view->hitInfo.cell, hlevel, hxc, hyc, hzc);
double hscale = CELL_SIZE*(1 << hlevel);
double hx = hscale*(hxc + (float)view->hitInfo.voxel[0] / BLOCK_DIMENSION);
double hy = hscale*(hyc + (float)view->hitInfo.voxel[1] / BLOCK_DIMENSION);
double hz = hscale*(hzc + (float)view->hitInfo.voxel[2] / BLOCK_DIMENSION);

If you are adding blocks, the new block may be not the focused block, but an adjacent one. The VoxelHitInfo structure also contains information about which block will be added if you start from this location. The hitInfo.outsideDirection[3] vector will tell you this. The next block to be added may be shifted from the focused block by an increment of one on either axis. So if hitInfo.outsideDirection[1] is 1, that means the next block to be added will be the one right on top of the current block. Since you know the block sizes on each direction, you can compute the bounds for the future block in a similar fashion to computing the focus block.

3) To modify voxels directly, you need a pointers to a CBlockData and a CClipmapView. The plugin implementation contains these in VoxelFarmWorldImpl class. The overall approach is you use the CBlockData interface to write the voxels and the CClipmapView interface to make sure the scene updates to reflect your changes.

The first step is to use the blockData interface to load a cell. The fetchData() function will do this. The parameters are the ID of the cell you want to load, and "true" to tell the system you want to create a new cell if none is found.

BlockVoxelData* data = blockData.fetchData(ncell, true);

The BlockVoxelData object contains the voxels for that cell. You can then modify the voxels directly by calling:

data->setMaterial(BlockVoxelData::Index(vx, vy, vz), material);

Where (vx, vy, vz) are the local coordinates of the voxel within the cell (ranging from 0 to BLOCK_DIMENSION) and material is the numeric material ID for the material you want to write. Zero is air, which can be used to delete.

You can also set the voxel vectors this way:

data->setVector(BlockVoxelData::Index(vx, vy, vz), 0.5, 0.5, 0.5);

The example above is passing a vector to the center of the voxel, which would make for perfect boxes, but you can position the vector anywhere you would like to achieve the desired surfaces.

Once you are done modifying voxels, you need to tell the ClipmapView to update, so the modified cells are recomputed and visualized. This also triggers computing the other Levels of Detail for the content you just wrote. To do so, call:

clipmapView.processModifiedCells(changedCells, false, NULL, false);

Here changedCells is a set that contains the CellIDs of the cells that were affected during the operation.


Answers to you other questions are coming later in this same thread.
1 0
JBone
I'm also encountering the StampMesh blueprint function not using the material id. In the code it just turns it into the remove bool with VoxelMaterial == 0. I'm trying to modify it in VoxelFarmStampMesh. The stampMeshQEF takes in a IMeshStamMaterialSource, and I'm not sure how to get that from a materialID. I've tried doing clipmapView->buildMaterial = matid before calling the function, but it did not change. Is this something I will be able to do on my own or will I need to wait for an update?
0 0