SAVE terrain to Blueprints

[Steelbound]

lease let us save terrain to blueprints. at this moment if you want to save an underground coaster, you can not place it underground when you want to use the BP. so let us save the terrain too.

also a lot of cool BP use the terrain tool to make it look awsome. but we cant save this terrain. so the only way to save a mountain, is by making a mountain with rocks. wich increase your scenery usage drasticly.

i know its probaly weird to save it, but please just let us save a chunk of terrain. we can always brush the terrain flat if it sticks out weird.

I love to make mine coasters and terain sculptures, but i cannot share these creations.

 

[Curlyriff]

Sorry but the voxel terrain is locked to the map. The only way to make this work is to use the park itself that it came from and then place everything else in wit the coaster.

It won't change. I am not aware of any software/game in the world that you can do so with voxel terrain system.

 

[Inge Jones]

Do you think that might be the same reason we can't save paths to blueprints too?

 

[Curlyriff]

No I don't think so because they can be separate such as just as a floor in a building with a path around it. It is no different to a coaster track really. They also dynamically lock to terrain with footings. I don't see any technical reason we couldn't have the path save with the building.

Now the collision system would have to change to drop the path down to the terrain level, however if you have a 1st floor built in the building then you could then connect to grid with the existing path once you have got the level correct with said building.

 

[Inge Jones]

If paths were included in blueprints I would rather the path remained exactly the same height relative to the building pieces in the blueprint, so that I could decide how to make the connection between the blueprint path and the terrain. For instance I may decide to simply sink the whole building into the ground a little way, or build steps up to where the bp path starts.

 

[Curlyriff]

If paths were included in blueprints I would rather the path remained exactly the same height relative to the building pieces in the blueprint, so that I could decide how to make the connection between the blueprint path and the terrain. For instance I may decide to simply sink the whole building into the ground a little way, or build steps up to where the bp path starts.

Yep so what I am saying is currently the issue is the path doesn't reform the terrain but conforms to it.

If you have your path attached to the building on the ground floor with an external length of path then when you place it on the terrain it would have to be perfectly formed to the path you have created. However if you could place the building and snap to top of terrain and it flattens the rest of the terrain to suit the footprint then that would be amazing and allow it to work.

At the moment however I am not all that worried if it never happens as placing path and selecting grid means I can create the path tight to the building reasonably quick and if they add a click and drag across the grid system so you can make plazas super quick then I really won't mind.

 

[Inge Jones]

But what if we had a building, such as a fairy castle, that was created with a hillside in mind? Or something that was intended to be half buried? I wouldn't want anything snapping or flattening to anything really. I'd like to carefully place the building, along with its inbuilt paths, to the exact height it seemed to blend in best, then mould the terrain around it. **BUT** this does need Frontier to address another problem we have raised, which is the terrain refusing to touch a path. You can untick the "Lock to scenery" button when terraforming up to walls, but paths insist on remaining clear from any attempt to bring the earth up to meet them.

 

[Curlyriff]

Aye I think the best you would have is to place the building and then have the ability to pull the terrain too it rather than trying to get the game to work out where the path is and how it should connect between.

It just needs them as we are saying to update the terrain so that it can be pulled to the underside of the path system and then all will be good.

 

[skn3]

Sorry but the voxel terrain is locked to the map. The only way to make this work is to use the park itself that it came from and then place everything else in wit the coaster.

It won't change. I am not aware of any software/game in the world that you can do so with voxel terrain system.

The voxel terrain is created in code, so therefore it can be added to with code. There is no reason the system couldn't save an area of voxel terrain in a blueprint. When you are placing it down, it would have to simply calculate the union operation of the two voxel shapes. Of course that is a tricky procedure, but that is what programming is about.

 

[Inge Jones]

And at least it would only need calculating once, at placement time, where a tiny lag time for calculations is acceptable.

 

[Curlyriff]

The voxel terrain is created in code, so therefore it can be added to with code. There is no reason the system couldn't save an area of voxel terrain in a blueprint. When you are placing it down, it would have to simply calculate the union operation of the two voxel shapes. Of course that is a tricky procedure, but that is what programming is about.

I understand the principle but there is a lot more too it as well. simply calculate the union as you say is not all that easy. Certainly not for a desktop computer whilst you are playing a game. It uses a wire frame system which we push and pull about and re-skins as you move it to stop texture stretching.

To try and snip that out would take a whole host of new tools that would need to be put into the cobra engine. The only parts of systems that do it to an extent is such programs as Mudbox and Maya. However those are specific pieces of software costings thousands and so it really is something different.

We will always be better having blue prints without terrain I feel. Not to mention the size of the saved item too.

Last of course the only thing that would be awesome is having auto tunnel work when you place the coaster. If you could turn it on and by just lowering it whatever is below could just cut the terrain out including the station even. That would be cool and probably easier to do than cut the ground out with it to start with.

 

[skn3]

I understand the principle but there is a lot more too it as well. simply calculate the union as you say is not all that easy. Certainly not for a desktop computer whilst you are playing a game. It uses a wire frame system which we push and pull about and re-skins as you move it to stop texture stretching.

To try and snip that out would take a whole host of new tools that would need to be put into the cobra engine. The only parts of systems that do it to an extent is such programs as Mudbox and Maya. However those are specific pieces of software costings thousands and so it really is something different.

We will always be better having blue prints without terrain I feel. Not to mention the size of the saved item too.

Last of course the only thing that would be awesome is having auto tunnel work when you place the coaster. If you could turn it on and by just lowering it whatever is below could just cut the terrain out including the station even. That would be cool and probably easier to do than cut the ground out with it to start with.

I think you under estimate the requirement for this operation. All decent 3d modelling packages have Boolean operations for dealing with this type of thing on geometry. Its even possible with javascript:
http://shapejs.shapeways.com/creator?example=subtraction

(which is going to be order og magnitude slower, just because its Javascript).

PC could generate the voxel stored in the blueprint as a static mesh. It then displays this under the mouse cursor to indicate where you are placing it. No merging has to happen here on the fly. When you click to place, this is when it does the one time merge operation. If there is lag, then in UX design this an acceptable lag as you have already confirmed your action.

 

[Curlyriff]

I think you under estimate the requirement for this operation. All decent 3d modelling packages have Boolean operations for dealing with this type of thing on geometry. Its even possible with javascript:
http://shapejs.shapeways.com/creator?example=subtraction

(which is going to be order og magnitude slower, just because its Javascript).

PC could generate the voxel stored in the blueprint as a static mesh. It then displays this under the mouse cursor to indicate where you are placing it. No merging has to happen here on the fly. When you click to place, this is when it does the one time merge operation. If there is lag, then in UX design this an acceptable lag as you have already confirmed your action.

Hmm maybe, however with the size and complexity of what we are doing I just feel the lag may be to the point you are going to get a cup of tea at least on much older systems. If we was all running i7's at 4.5GHz etc then yeah I could see it working.

I understand the principle, just not sure the cobra engine would be so light to do so whilst in game that is all.

 

[skn3]

Hmm maybe, however with the size and complexity of what we are doing I just feel the lag may be to the point you are going to get a cup of tea at least on much older systems. If we was all running i7's at 4.5GHz etc then yeah I could see it working.

I understand the principle, just not sure the cobra engine would be so light to do so whilst in game that is all.

Hehe well you just hit on the right idea. Have a progress bar, the game predicts how long its gonna take. Warns you, then instructs you to go make a cup of tea

 

[Curlyriff]

Hehe well you just hit on the right idea. Have a progress bar, the game predicts how long its gonna take. Warns you, then instructs you to go make a cup of tea

Honestly I would love it to work but of course for the whole community so maybe they can prove it possible as they work on the Cobra engine.

 

[Inge Jones]

tbh I don't see why combining should take much longer to process than manually editing. I thought the whole point of voxels is they occupy volume so the type of maths involved should be more natural to a voxel type situation than a pair of normal meshed objects?