ModTer/OpenGL suggestions

[[GSF]Ghost]

I know some of these have already been suggested, however I'll unify them into one thread. I think the following would be important to implement, especially when Blockland is released on Steam Greenlight.

-Fix brick-culling for triangular faces (in which two vertices share the same location; for normal and ModTer bricks).
-Fix brick-culling for zonal bricks (it seams to reference the bounds of the zone rather than the brick's coverage).
-Add a tertiary building layer so that Modular Terrain bricks will be compatible with normal and other zonal bricks).
-Allow Add-Ons to access OpenGL functionality (or at least include functions for procedurally drawing meshes). This would make infinite terrain generation MUCH easier. Terrain could be made to look realistic, flat-shaded or even like regular bricks.

[Ad Bot]

[Wesley Williams]

This sounds like a great first step for Blockland on Steam. I know Badspot is busy with Steam implementation, but hopefully once that has all been worked out he can work on these issues first. This would also really help with more terrain back in Blockland again.

[Zacks]

If we had access to opengl funcintionality. And such would we be able to make terrain render like regular terrain from v20 or some other terrain program?

[SWAT One]

I would really like to see this, especially the new build layer.

[[GSF]Ghost]

If we had access to opengl funcintionality. And such would we be able to make terrain render like regular terrain from v20 or some other terrain program?

I'm pretty sure you can make it render like v20 terrain. You can also easily setup smooth or flat-shading depending on how you draw the mesh. It could also allow interiors to be brought back (they could be built using in-game programs), possibly with shader-support.

I would really like to see this, especially the new build layer.

I just realized that another build layer could possibly be added via packages that overwrite the brick functions. I'll definitely look into this.

[Lugnut]

if we had opengl access, could we not render whatever the forget we want?

[Axo-Tak]

OpenGL support would probably be awkward in TorqueScript.

[Marcem]

I'm pretty sure you can make it render like v20 terrain. You can also easily setup smooth or flat-shading depending on how you draw the mesh. It could also allow interiors to be brought back (they could be built using in-game programs), possibly with shader-support.
I just realized that another build layer could possibly be added via packages that overwrite the brick functions. I'll definitely look into this.

If making terrain was that easy, don't you think badspot would have done that already?  Opening up OpenGL access, even though that makes no sense, would open a giant can of worms.  Especially with the scripting skill of people here, I wouldn't want everyone's crappy graphics programming running in the game.  Already the game is weighed down heavily by cascaded shadow mapping when trying to run thousands of bricks, and there's no real good way of going about optimizing the bricks even more.  You seem to have absolutely no clue how this works at all.

[Port]

OpenGL support would probably be awkward in TorqueScript.

OpenGL support is awkward in every language ever.

-Allow Add-Ons to access OpenGL functionality (or at least include functions for procedurally drawing meshes). This would make infinite terrain generation MUCH easier. Terrain could be made to look realistic, flat-shaded or even like regular bricks.

This really doesn't make sense because OpenGL would be a client-sided thing, and terrain generation should be done server-sided.
Sending rendering primitives to clients is simply not an option due to how horrendously slow it would be.

[[GSF]Ghost]

OpenGL support is awkward in every language ever.

This really doesn't make sense because OpenGL would be a client-sided thing, and terrain generation should be done server-sided.
Sending rendering primitives to clients is simply not an option due to how horrendously slow it would be.

Actually, the terrain generation could be handled via a client-sided algorithm, but it would check with the server for each chunk if it was edited. If it's edited, then the server would send the mesh data to the client. Also, if done client-sided, each client would be able to adjust the radius of chunks generated around them.

If making terrain was that easy, don't you think badspot would have done that already?  Opening up OpenGL access, even though that makes no sense, would open a giant can of worms.  Especially with the scripting skill of people here, I wouldn't want everyone's crappy graphics programming running in the game.  Already the game is weighed down heavily by cascaded shadow mapping when trying to run thousands of bricks, and there's no real good way of going about optimizing the bricks even more.  You seem to have absolutely no clue how this works at all.

I didn't say it was easy. Also, I don't have experience directly with OpenGL, but I do have a lot of experience with infinite terrain generation and drawing meshes procedurally:


Anyways, it was just a suggestion; I left it open-ended on purpose for discussion.

if we had opengl access, could we not render whatever the !@#$%^&* we want?

Yeah, that would be a major problem; it might be best to restrict it in some way; not sure how though.

[Port]

Actually, the terrain generation could be handled via a client-sided algorithm, but it would check with the server for each chunk if it was edited. If it's edited, then the server would send the mesh data to the client. Also, if done client-sided, each client would be able to adjust the radius of chunks generated around them.

That isn't just raw OpenGL API access, that's an entire new framework for map formats and rendering.

[[GSF]Ghost]

Okay. I do have infinite terrain generation for the game pretty much already figured. But, the point I wanted to make was that using the current brick-system is really inefficient for generating terrain. Culling brick-chunks would lag quite a bit, and I don't have much control over delaying other chunks from being generated while waiting for bricks in the current chunk to render.

For me (and I'm sure others as well), when maps and terrain were removed, the game just lost a lot of appeal. I thought adding terrain generation would be a great addition, especially with the Steam release. If anyone has ideas on how to improve performance with generating brick terrain, it would help. Then, I wouldn't have to draw meshes externally.

[Wesley Williams]

Bump because this is important.

So long as the brick culling remains like it is, modter will not reach it's full potential.

[honytawk]

If anyone has ideas on how to improve performance with generating brick terrain, it would help. Then, I wouldn't have to draw meshes externally.

If I can give my opinion, terrain generation does not need to be fast, it only has to generated once.
After that, ghosting is already implemented pretty well, as long as the biggest bricks possible are used and no unnecessary bricks are placed.
But here is an idea: if the bricks are floating, bricks under it don't need to be generated. You only have to make it so the terrain bricks do not break when a brick on it is hammered. Make them act like real terrain.
I don't know if this is possible, but I think you know this better than me.

[beachbum111111]

I know this isn't that relevant with the thread but I think it would be awesome to have some sort of in game brick editor for ModTer. It would be easier to make smaller details when your trying to make terrain or interiors out of bricks. I don't really know if it's possible or not though.