Hey everyone, I think this is my first post here in the forums although I have been lurking for ages. So I thought I would drop something I have been working on recently to get myself into the habit of posting things.
Basically I am working on small greyboxing tool based from the ‘slabs’ system Jonathan Blow created for use in blocking out the puzzles in The Witness. A similar system has been used on the game Obduction for prototyping, a little video of it in action here (somewhere in the middle they show it):
The slabs are basically just cube actors that are places in the level and when a modifier key is held down above a face you can drag it along it’s normal to stretch it out, this always works locally so you don’t get any nasty deformations or anything unexpected going on.
Currently I am working on a blueprint prototype with plans to turn it into a C++ version after that once I’ve figured out the logic (As I’m only just starting to learn C++). At the moment it works simply by dragging about 3d widgets placed on each face that are constrained to an axis but eventually I want to do away with that and access the face directly using the mouse and selecting a modifier key.
I made this earlier which taken me about 5-10 minutes, it’s very intuitive to use and combined with grouping and rotating makes it very efficient for creating level prototypes.
The only problem at the moment is that unlike the slabbing system the pivot currently doesn’t reset to the center of the actor after an adjustment is made, this is a hard one though since I have to access the relative location and all the points are being moved independently of the objects origin and I haven’t quite figured out the maths behind it yet to get it to work. I’ll upload a video soon showing properly how it works anyway.
Here is what I’ve got so far, made a quick video showing myself messing about with the blocks.
I’m continuing to work on the pivot problem, as you can see in the video if I move the sides of the cube the pivot doesn’t update to be back into the centre of the cube, this actually requires quite a bit of reworking by the looks of things as when you offset the root pivot you offset everything in the actor, and then you have to take that away to keep the points where they were before. I think… Apart from that the slabs function quite well!
Yeh I was just thinking along the lines of something like that, I mean there is a similar mesh scaling feature inside the VR editor I believe so I’m surprised that’s not in the main engine version yet, maybe it will be soon and render this work pointless. I will put it all on marketplace though when I get a C++ version working that works with the mouse, but I’ll probably include the blueprint version aswell that could be mesh swapped. I’m thinking the C++ version will be nice as you can select the side bounds of the mesh like a face and drag it out instead of a widget.
Ok I’ve been experimenting with some other basic shapes while I figure out how to create the pivot offset, at the moment only similar sized meshes can be used and the pivot must be centred. I imagine this would have to be fixed along with the pivot offset as you would need to offset the mesh component from the root depending so the slab’s mesh is always centred. I’m working on that atm though, it’s harder than I thought it would be.
Finally fixed the pivot problem, now the slabs pivot autocentre correctly. Also I have added a small feature to disable the mesh and replace it with a box collision, allowing the designer to use placed slabs as the level collision underneath finalised assets.
I’ve tried to improve the video quality a bit more aswell, something I’m trying to improve as I do more of these updates.
Awesome work. If you need any C++ help, both coding and questions. i’d be happy to help as this is something i wanted but i’ve yet to get around to making.
Cheers, much appreciated. I got the C++ version working (mostly) last night. I do have a little problem with it though that I don’t seem to have with the blueprint version. Basically to get the end position of the root pivot so it always stays in the center of the slab I use this to get PivotOffset which I subtract from each control point, so the Slab’s root is always moving but it’s unnoticeable as the control points are compensating for it. I think. When I add a new Slab to the scene the base actor position is offset before doing anything to it, but as soon as I move a node though it corrects itself.
[FONT=Courier New]
//Get Pivot offset and set root position
FVector CurrentMeshLocation = Mesh->GetComponentLocation();
FTransform SlabTransform = GetActorTransform();
FVector SlabWorldLocation = SlabTransform.GetLocation();
//Create Point Offset Vector by converting world space movement to local offset that can be subtracted from control points
FVector PivotOffset = (SlabTransform.InverseTransformPosition(CurrentMeshLocation));
SetActorLocation(CurrentMeshLocation, false, false);
I have tried to put it inside an if statement checking if CurrentMeshLocation is equal to SlabWorldLocation, hoping that on spawn it wouldn’t trigger the setlocation but it didn’t really do anything, is there something I’m missing?
I thought so, This is exactly the same problem im having in my Lindenmayer System plugin. Maybe we can summon an epic dev to give us some information about C++ and the use of world space to local and vise versa and how to not get local movement offsets when moving in world. Because BP holds your hand for local to world. whereas C++ forces you to manage both. I’ve tried almost every combination of relative/world set/get/add and i still cannot figure this same problem out.
Edit: I never really had a problem with adding things in C++ then moving in the world and having this weird offset. I have to be overlooking something.
@Michael_Noland Any insights to why when we move stuff in world space, object in its local space are offset ?
It would be a useful consideration to be able to make it so the mesh uses complex collision (polygonal collision rather than primitive collision) as an option.
Yeah the offset I don’t quite understand, because technically on spawn the mesh and the root component would be in the same place so it shouldn’t offset anyway, so I have no idea where this offset is coming from. I can’t find anything else in the code aswell which would give it that sort of position. :S
Oh yeah, I have that noted down. I might actually work on that now as the custom mesh stuff needs some work anyways.
This is really neat. I can definitely see this being very popular as a replacement for BSP for greyboxing for sure, as well as very useful for low poly environment design! Awesome work.
Are you considering releasing it via the marketplace or something? Would love to get this in my library for future use when I finally get to working on games instead of marketplace content XD
I will put it all on marketplace though when I get a C++ version working that works with the mouse, but I’ll probably include the blueprint version aswell that could be mesh swapped. 
