Theme Park Builder 3D

I read through everything I could that was said about the BG and tried to write it down as succinctly as possible.

In the process, I identified a complementary missing feature that should go with the BG...Tunnel Extrusions. This new feature will make it easy to make tunnels and complex corridors within buildings and paths.

Can the coders please review the attached document and critique it?

DEAD LINK "AC" - - Get BG Functional Specs

I need commentary on my understanding of the BG as complete before I try to make a pre-visualization of the BG in order to try to find any flaws or issues with it.

Can the coders review the doc?

From a coding perspective I'm not particularly concerned about the front end, my fears lie with the mesh generation asepct of the problem. If someone could actually solve that problem, then I would be a lot happier.

In order for the BG to work the mesh has to be generated procedurally. If you design the mesh in a 3D package it's not scalable and is functionally no different from placing any other piece of scenery, at which point the BG interface is irrelevant. The primary problem is therefore to specify how BG meshes are created and the mechanism for allowing the end-user to manipulate whatever generates the meshes. The generation mechanism needs to open ended so that content creators can create new content. The UI need to be adaptive to cope with different BG generation scripts presenting different parameters that can be adjusted, we don't want to have to create a fresh UI for each BG generator.

Punching holes in an existing mesh in computationally non-trivial. I really don't want to have to go there, if the holes aren't coded into the BG mesh they're not going to be there.

Restaurants, amusement arcades, swimming pools are covered in a Zones paper which I have yet to write up because I'm doing everything else. Some details might be in my WTF thread.

In principle you are right, but in this case it may be worthwile to think about the frontend first. The reason for this is what we need to start is defining the input for the generation scripts, which may be easier thinking how it would be exposed in the front end.

I think that defining the input for the generation scripts is the key point, ie. the creator front end, but this shouldn't be driven by the player front end.

Whilst it may not be the most aesthetically pleasing UI, if the generation scripts provided a list of parameters that can be manipulated, then these can be presented to the user as a two column table of names and values, with the second column being manipulable. Anything else is graphical sugar on the original premise, which is "parameters can be presented to the user for manipulation". An example of more sophisticated manipulation would be that height, depth and width could be manipulated by dragging a box within the environment, but they could equally have been manipulated through the table mechansim.

Once you have made the above assumption it boils down to how do we define a procedural language for creating meshes. Which means we have to start defining programming constructs in terms of loops, conditionals, function evaluation and simple variable handling. Such a language could be extended almost indefinitely, so we need to decide what are the key features that are required to generate the sort of buildings that they want generated.

Thank you for your response. I was not concerned about the UI either, I just put the pic up for eye candy.

I wanted to prompt a discussion about this particular feature, because I am sensing serious logistical and performance issues with this feature as it is described in the forums and wanted to get your feedback now rather than letting this thing get too far in people's minds without a reality check.

By getting a pre-visualization, we can perhaps gain a better understanding on how this thing is suppose to work in a visual way that helps everyone get on the same page and makes it easier to see subtleties both positive and negative.

I was looking into boolean operations on 3D meshes and it is most certainly not a trivial endeavor personally and computationally. However, since the visual purpose of punching holes into a mesh is to allow internal viewing from the outside (NOTE TO NON-PROGRAMMERS: Peeps walking through doors can occur with or without holes in a mesh), can we use a cheat?

Specifically, instead of altering the geometry of the mesh, can we just project a texture into the mesh that makes the intersection of the projection and the mesh see through? Sort of like a transparent shadow.

To bad my post about this got lost, cause it was nice.

But to make it simple I think all our objects should work as primitives in a 3D program.

ex. Take a cube and the user can change the hight with and length of the object.

So basically all basic meshes should be done from a primitive stand point and then for pieces that are complex and wouldn't be done with primitives should stile have scale abilities on the xyz axises independently.

As boolean operations while I never even thought of it before this it does exist in many low end 3D programs now so it shouldn't be to hard to do it if we wanted. I believe I even know some open source modelers we might be able to get some code from if needed.

As for how this will be done from the back end I think we need our own easy to use scripting language. Take a look at anim8or's scripting language ASL somthing like that but simpler meaning taking out every thing not related to primitives could work.

And then once the coders implement it and give us some documentation and examples then it is up to us the scenery makers to learn it.

I'm sure that there is some way to punch holes through objects using OpenGL magic, possibly the stencil buffer or some funky magic with the depth buffer. However such a mechanism would have to be invoked every render cycle, which would slow things down, much better to punch holes in the mesh at mesh creation time and then cache that for evermore.

Might be able to do something with alpha textures, not sure what the resolution would be like whether you'll get aliased edges and the punching would only apply to viewpoint facing polygons, you wouldn't see the inside of a thick wall because the rear facing polygons will have been culled.

Where does the punching stop? How do we know when we've punched through the first wall.




Agents will walk along paths regardless of what scenery that path passes through, I don't intend to implement agent collision detection since it would cripple the system.



Regarding a scripting language, we can either hand-roll our own in XML, or use something like Lua to provide the language framework.

Thanks guys for responding to this thread. I am very comforted with what I am hearing so far.

The transparency projection is intended to travel only 1 or 2 units from the decoration. In my illustration, it is greatly exaggerated and I failed to point out that fact.

With regards to actually punching holes or using texture cheats, I leave it in your capable hands as to the best method. I was under the impression that actually modifying the mesh was somewhat of feat both programming wise and computationally.

*** Am I correct in thinking applying textures is computationally less expensive than a mesh with holes on a frame-by-frame basis?

Alpha textures sound like a good idea. Perhaps we can gleam the decoration silhouette and just map it onto the mesh at corresponding coordinates to the decoration and poof! Holes. It would even work for non-flat surfaces (track entry/exits), but not for decorations (windows and doors).

On a slightly different topic, decorations (windows and doors) require flat vertical surfaces that in the RCT way of building is a non-issue. In our emerging BG method, it needs to be resolved.

The reason I specifically differentiate decorations (in my BG Design Doc) from scenery (which can be arbitrarily placed any where like in RCT) is that decorations require flat vertical surfaces.

Doors, windows, signs, flags are all decorative items and need flat vertical surfaces.

Scenery items like trees, stalactites, chandeliers, etc. can be placed any where at any height.

By defining things in this manner, it is hoped that developing the BG is simplified a bit.

Rhyss Wrote:The transparency projection is intended to travel only 1 or 2 units from the decoration. In my illustration, it is greatly exaggerated and I failed to point out that fact.

What if the entire building is only half a unit wide, you've punched a hole in both sides of it if you punch for 2 units. There's a lot of logic involved in knowing where wall begin and end.

Rhyss Wrote:With regards to actually punching holes or using texture cheats, I leave it in your capable hands as to the best method. I was under the impression that actually modifying the mesh was somewhat of feat both programming wise and computationally.

*** Am I correct in thinking applying textures is computationally less expensive than a mesh with holes on a frame-by-frame basis?

Alpha textures sound like a good idea. Perhaps we can gleam the decoration silhouette and just map it onto the mesh at corresponding coordinates to the decoration and poof! Holes. It would even work for non-flat surfaces (track entry/exits), but not for decorations (windows and doors).

On a frame by frame basis alpha textures and modified meshes are about on a par. A modified mesh might take longer to render because there are more polygons, but equally submitting an alpha map to the graphics card takes an amount of time since it can be quite a large amount of data.

Both mechanism are pre-calculated, ie. the mesh or the alpha texture are calculate when manipulated rather than on a per-frame basis.

Rhyss Wrote:On a slightly different topic, decorations (windows and doors) require flat vertical surfaces that in the RCT way of building is a non-issue. In our emerging BG method, it needs to be resolved.

The reason I specifically differentiate decorations (in my BG Design Doc) from scenery (which can be arbitrarily placed any where like in RCT) is that decorations require flat vertical surfaces.

Doors, windows, signs, flags are all decorative items and need flat vertical surfaces.

Scenery items like trees, stalactites, chandeliers, etc. can be placed any where at any height.

By defining things in this manner, it is hoped that developing the BG is simplified a bit.

Decorations need to be attached to a polygon within an exisiting mesh. The wrinkle here is that we need to be able to uniquely identify each polygon, across manipulations of the parameters, which can potentially change the number of polygons and their ordering within the mesh, therefore we can't use index within the mesh as a basis.

For example, lets say I've created a dome structure with 8 sides and added decoarations to it. If I change the dome structure parameter to make it 10 sides I don't expect all of my decorations to disappear I expect two new sides to appear that I can attach fresh decorations to.

- I favour using an existing scripting language. The generation is not time-critical. I'm not sure it should be lua, as (at least least to me) it seems not to be used widely besides internal scripting. I'd favour something people might already know or be able to use elsewhere in more general terms. Long story short, I'd rather use Python or Ruby.
- Well, I'd put the hole punching off to the script editors. For example a window script can tell the building script "I need a hole this size there!", the building script says "Fine, here you are. Remember, my walls are this thick, so adjust to that."
- Scripts could manage attachment points for decorations which should follow a reproducible scheme, that would allow for your dome example to succeed. This attachment point defines a local coordinate sytem into which the decoration is projected.

Remember though that what every script we use we have to make sure is easy enough for people to pick up on not just something that would take a pro coder to understand, other wise it will make it fall on coders instead of scenery makers.

Cook I think you might be a bit confused with how boolean operations work in 3D programs being you make every thing by code

Now I am going to set this up as if I was in a 3D program not a game.

Now I build a wall 4 high 4 wide 1 deep

Now I want to put a hole it it for a window, so now I build a cube 2 by 2 by 2 and center in the wall for where I want the hole.

Then when I execute the boolean operation the cube will disappear and there will be a hole in the wall the exact size of the cub and the actually model of the wall will change deleting and adding faces as needed.

Well, we'll need some kind of full capability scripting language for the game, no sense to invent yet another thing for this. Either people learn it and contribute or they don't. As a few will exist, they can simply learn from example.

I'm not really clear how the scripting method would address the BG, but if others understand, I'm satisfied that it is a relevant approach.

As for boolean operations, here's a visual example:

Before:


After: