-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for overlaying one 3D Tiles tileset with another (clipping) #47
Comments
Currently we have a hacked-up system based on a list of "cutout" rectangles. Cutouts can only be used with raster overlays, and they work by a) setting the alpha value to 0.0 of any pixels in overlays inside any cutout rectangle, and b) applying the overlay's alpha value as an opacity mask. This has some problems:
CesiumJS uses clipping planes, but it's not clear if we can do that in the UE material system. I don't know what the right answer is here, it will take a lot of research. Given that a perfect solution may be elusive, we will probably need to focus on some key motivating use-cases in the first release. |
Talking to some potential users yesterday, it became clear that it's probably not sufficient to just clip away the model. It's also necessary to blend between the two models so that we don't get cliff faces or holes where they meet. Adjusting vertices so that the two datasets line up probably requires assuming that the datasets are 2.5D-ish. The same folks were saying that in the rare case where the datasets aren't 2.5D at the place they meet, they sometimes (in the past) have created custom geometry in 3ds max or whatever to join them, and then blend the bigger dataset with the custom geometry further back. |
One more thought on this - the ideal solution will allow you to inverse the clipping mask. This will be important for projects using just one section of Cesium World Terrain, or any other large tileset, and so they should be able to define a volume where only tiles within the volume are loaded. It would be awesome if we could make it as simple as a checkbox on the mask/volume to invert it. I don't know how the previous solution worked, but if we could prevent tiles outside the volume from loading at all, that would be optimal and solve the collision issue. I also think that ideally this would look like rectangular prism/cuboid (or spherical, or whatever is easiest) volume that players could drag in and scale to fit their needs. Ideally they'd be able to drag in multiple, and select which tilesets got clipped on a per-clipping actor basis. I'm kind of picturing Unreal's Geometry Brush Actors, which are used for prototyping levels. You can set these 3D brushes to be additive or subtractive, which is very cool, though I don't think we would be able to implement clipping volumes in exactly the same way. |
UE has a thing called Procedural Meshes. We can create one from a normal static mesh, and then do a Slice Procedural Mesh on it to cut it with a plane and optionally cap the sliced edge with geometry. Pretty fun demo using it here: https://www.youtube.com/watch?v=oIdKxYYQBdw It also slices the collision mesh, but apparently only if it's a "simple convex collision", which ours are not (or at least not guaranteed to be). |
I was hoping there would be a place to insert some extra logic to "filter out" collisions with clipped-away parts of a mesh just-in-time. i.e., after a collision between a pawn and a tileset is detected, check to see if the collision is actually with a clipped away part of that tileset, and ignore the collision if it is. There are some good tricks for discarding the clipped-away parts when rendering, so if we could do something like this for collision queries we could potentially save ourselves the trouble of actually modifying tile meshes for clipping. So I spent awhile tracing through how collision works, starting with Once a collision is detected inside
So unfortunately this looks like a dead end, at least without modifying the engine. |
@kring I went down the rabbit hole for a couple hours today and I found two potential leads for "physics culling".
|
Also some more talk about contact modification on UDN: https://udn.unrealengine.com/s/question/0D52L00004luiWbSAI/controlling-character-vs-rb-collision-response |
Just to keep this issue in-the-loop as far as what is being worked on, the priority as I understand it is:
For 2.5D, I'm planning on using Unreal splines to define arbitrary concave polygons to cull, I think it will be a convenient interface for users. On the other hand, I'm not sure what the best interface would be for users to define arbitrary 3D polygons if we decide that's something we want to do as well. |
Fixed in #446, even if there's more we can imagine doing in the future. |
So that we can have a "base globe" tileset and then overlay smaller, more detailed areas from another tileset. For this issue, we only need something good enough for the primary use-case of "show a globe, let the user zoom in to a more detailed area" and we should aim to keep it simple. But if it's not much more time consuming to implement the latest approach in CesiumJS, we should do that instead.
The text was updated successfully, but these errors were encountered: