#1 2015-10-11 16:27:40

MajorLunaC
Member

Idea: Pseudo-Desctructible Environments?

I've seen rare mention of destructible environments on the forum, and then only involving a lot of work. My question is, why would it take so much work if the maps are already client-editable? Can't a weapon be made to just shorten the objects hit via edit mode? If you wanted more realistic effects, maybe have a thin charred rough mesh or wall bits with no hit-box appear in front or something similar (and of course a big fancy explosion with debris to hide the transition)?

I don't think you actually need to destroy anything unless it can't get any shorter, so overall it would be a Pseudo-Destructible environment. Isn't that enough? I'm totally not saying it wont take any work, but it would probably take a lot less work.

Offline

#2 2015-10-11 19:28:13

RaZgRiZ
Moderator

Re: Idea: Pseudo-Desctructible Environments?

There are a few problems with destructible environments and that is often the composition of the destructible material. Different materials react differently to damage and to varying degrees. In addition to that, when you remove a chunk, what's behind it? What kind of texture would fill the blanks? In technical details, how will you translate this sort of damage to the octree and how will the edited cubes affect the performance or the cohesion of the shape itself? Even if the map wasn't depending on the octree, the other problems i explained affect all scenarios and this is why so few engines actually provide any sort of destructible environments. Most are just scripted and pre made to fall apart in specific ways, fully knowing how each chunk will look from all sides. Others use a saturation method to the world's geometry so when they cut up the map the gibs already have texture information.

Offline

#3 2015-10-12 02:18:11

chasester
Member

Re: Idea: Pseudo-Desctructible Environments?

To add to RaZgRiz, cuz i feel that his first point is kinda mute and most of the texturing decisions could be prescripted cuz every cube already has a texture. Damage and amount could be predetermined by the texture and you could simply just create a "destroyable" material so the engine can simply guess most of that, and lastly wrote a simple transition effect for each type of destruction, most of the visuals could be done fairly easily that's not even half of it though.

Now there is the oct tree, simply put destroying the word causes a lot of inefficiencies. All the optimization done before hand are null, the tree is now more complex meaning longer render time and physics times. Assuming that you wrote the relatively hard algorithm to run the map opt over multiple frames, and then assuming in this case your using bullet physics (cuz why would you not) you would also have to update the mesh for bullet. Both of these calls take about (3-5 seconds each). So running this over multiple frames with a about 5-10 second transition would work (running the physics opt then the map opt then the physics op again).

Now you could build on this efficiency cuz really only one small part of the map really needs reopt so maybe you could pull this down to about (0.5 to 2 secs each, this may allow with a long enough transition time to allow you to cut it to just map op physics op)

Not really that bad, well that's for one calculation, this becomes even more daunting when you have 16 players on a map trying to do this, you could take any were from 8 - 32 seconds to do all these calculations. assuming that none of them overlapped and mad other ones void.

So you would have to write yet another call, to check the integrity of the map to see if it was worth just completely recalcing  everything or just one thing. And write in optimizations so that it could bulk the calculations together, and ran the modifications at the same time.

This problem exponentially grows the larger the map is.

This is all so you can blow a lil whole in the wall, and probably find some hack to kill everyone through some cranny that they cant shoot back through. Most likely killing every ones game play experience and killing all the fun.

SO the point is, the work out weighs the goal. It doesn't enhance the game play experience enough to be worth trying to make this work

Something i have experimented with is small dents in the world, where ass a small indentation (not a hole) may appear at particular parts when hit, nothing that would break the physics. If you want a destroyable wall just create a flat plane texture it the same as the world behind it, then remove the model on hit. SIMPLE and CONTROLLABLE.

I have look into this, and maybe at some point i may try tackling this, but for the most part its not worth it.
chasester

Offline

#4 2015-10-12 04:20:43

OnlyTheGhosts
Member

Re: Idea: Pseudo-Desctructible Environments?

Easiest solution for having destructible environments is to have models and maps designed for it. Triggered events. Need the same kind of thing as doors being triggered to open, lights going on or off, and elevators - for elevators, Tesseract needs more physics capability (ODE or Bullet perhaps).

Fully destructible environments are possible in one game that I know of available on github;
https://github.com/jeaye/q3

However, a fully destructible map assumes that all materials are exactly the same, and that wouldn't help the realism. Some parts of a map being destructible easily would be nice; like windows. Other parts of a map shouldn't be destructible beyond "marks" with normal mapping to enhance the roughness of the appearance; such as thick walls and the ground. Models and code for those models to behave in that way are what's needed - it would be animation.

Last edited by OnlyTheGhosts (2015-10-12 04:22:05)

Offline

#5 2015-10-12 17:09:37

MajorLunaC
Member

Re: Idea: Pseudo-Desctructible Environments?

Woah, woah, woah! Those are overly-complex methods! Reading all that, I started thinking of some "How many programmers does it take to screw in a light bulb" jokes ;p

I'm talking really really simple. In essence, a simple config keybind, like so:

alias C [attack; edittoggle; if $blendpaintmode [paintblendmap] [editdrag]; toggleeditmovecut; edittoggle]
alias V [attack; edittoggle; if $blendpaintmode [paintblendmap] [editdrag]; selcorners; toggleeditmovecut; edittoggle]

Except that autoexec.cfg didn't exist until I made it in the config directory in the non-installed tesseract directory, and "exec autoexec" or even "exec confg" don't work (not found), and nothing new happened in-game. I'm basing this on the following 3 pieces of info since they're the main sources of info I could find:

http://cubeengine.com/wiki/Using_the_Console
http://cubeengine.com/wiki/Scripting_Guide
http://cubeengine.com/wiki/Scripting_Tutorial

So, I'm guessing my problem is one or more of these below, if anyone would like to enlighten me:
1) Any custom configs go elsewhere. (/home/user1/.tesseract/config on Linux)
2) Full or expanded config path must be used.
3) autoexec.cfg is no longer auto-run on game/engine start.
4) bind should be used instead of alias when using semi-colons.
5) alias does not support semi-colons so the commands should be placed on separate lines instead.
6) There's a much better way of doing this.
7) This is so not what you should be doing.

I do really like that link for the quake 3 destructible environment mod, though! Looks impressive and being developed! Nice!

Offline

#6 2015-10-12 21:31:34

OnlyTheGhosts
Member

Re: Idea: Pseudo-Desctructible Environments?

I suppose this depends on the "reason" that you want to have a destructible environment. If it is for increased realism, then everything being removable equally in Minecraft style wouldn't seem to be the way of achieving it.

Offline

#7 2015-10-12 23:36:23

MajorLunaC
Member

Re: Idea: Pseudo-Desctructible Environments?

Interest and amusement aren't reasons enough? I'm trying to see how elaborate and interesting this engine can get, especially since it seems to be quite efficient and fast even on large scales.

This is actually the second time I've been verbally turned away from the Tesseract engine and toward a minecraft-like engine because I've been told a feature that would be interesting to have wouldn't work well on the Tesseract engine. The answer I keep getting is something along the lines of "Some guy made this engine so he could make maps with his buddies, and he didn't really make it to support or potentially support anything other than what he was thinking at the time." (No offense intended, especially since most of it is not my words.)

The last games I know had destructible environments of any sort, apart from minecraft-type games, were Soldner and Red Faction. I was since expecting more games to have some sort of destructible environments, especially FPS games (minecraft and the like are nothing without extensive mods).

I've been trying to work with minecraft-like engines, but nothing even comes close to Tesseract performance-wise except maybe an obscure one in very early stages (not moddable) and another written in bug- and vulnerability-ridden Java.

Offline

#8 2015-10-12 23:48:09

chasester
Member

Re: Idea: Pseudo-Desctructible Environments?

if you just want some simple catch all solution like that then simply just use a height map brush (bind h) either go into the source and modify the projectile code to call the height brush tool and execute it at the projectiles explode location. This would look much nicer than what you have coded above.

From my understanding of binds you would want to do:

bind "v" [your code; here; ]

I know in old saur they used something like this to create a variety of things through the script. But my suggestion is to look at anti cube it has a lot of this kinda hacky code in it already and i works quite well tho it is very limiting, and hard to follow.

Offline

#9 2015-10-13 01:16:47

OnlyTheGhosts
Member

Re: Idea: Pseudo-Desctructible Environments?

I'm not trying to fob you off, MajorLunac, but I'm wondering what the end goal is. It seems like you would like destructible environments with a realistic appearance - which would require that the type of material being destroyed is important - yet at the same time desire the destructible environment to be just deletion at an equal rate regardless of the type of apparent device/weapon used.

This has already been done in a Sauerbraten mod;
https://www.youtube.com/watch?v=VPdKX7UhneY

Lots of big squares, no difference in the level of destruction or area or volume regardless of the weapon.


Although I personally want to achieve this later;
https://www.youtube.com/watch?v=TStAcxBF768

So... what kind of destructible environment? Realistic or Minecraft style?

Offline

#10 2015-10-13 02:06:51

MajorLunaC
Member

Re: Idea: Pseudo-Desctructible Environments?

For now, the simplest and easiest way possible. Style can come after achievement, even if it would require a lot of reworking. Right now, a sort of "proof of concept" is in order, and other developments can be compared to it.

The problem is, not even this basic bind is working, and I can't tell why:

bind "C" [shoot; edittoggle; if $blendpaintmode [paintblendmap] [editdrag]; toggleeditmovecut; edittoggle]
bind "V" [shoot; edittoggle; selcorners; toggleeditmovecut; edittoggle]

Based on default.cfg , that is exactly the code for

left-click; enter edit mode; left-click to select; scroll to move/cut selection; exit edit mode

Except it's not selecting, and I find it odd that both up-wheel and down-wheel do the same thing, even if it is a toggle.

Offline

#11 2015-10-13 03:45:00

chasester
Member

Re: Idea: Pseudo-Desctructible Environments?

some of these commands take a second to render like the selection commands, so they take at least one frame to select and set up the selection.

so you have to add a sleep 1 [ code; ]

i did it for you cuz i was bored.

I did a lil source modification and inline scripting.

Basically outlining what i did:

First a source modification that simiply called the hmap::run command when a projectile is destroyed. Unforanately i couldnt figure out how to set it at the projectile origin, so i wrote a simple inline hack to make all things better.

So:
bind "MOUSERIGHT" [edittoggle; cancelsel; editdrag; sleep 1 [ edittoggle; ]]

so i simply toggled into editmode then canceled the current selection then reselect. then wait 1 mm second, and toggle back.

bind "MOUSELEFT" [shoot; sleep 100 [remip; PHYSrebuildLevel;]]

Then after shooting we need to do a few things to get the level to look better, so we simply shoot then wait and then remip (recalculate all the vertices to the most efficent way, then rebuild for bullet physics. BOOM :P

now the key problem is the remip and rebuilding of the level for bullet, these calculation how ever were faster then projected, and look decent on an unmapped leave but on a complicated level like complex, they took way longer than nessary, with the correct implimentation you could build on this to create something prettier faster and more robust. But for me this is about all i will do.

chasester

so ill leave you with a video:
video

Last edited by chasester (2015-10-13 04:11:03)

Offline

#12 2015-10-13 15:14:35

gaya
Member

Re: Idea: Pseudo-Desctructible Environments?

Whoa, that's amazing chasester! Does that work in multiplayer?

Offline

#13 2015-10-13 17:31:19

MajorLunaC
Member

Re: Idea: Pseudo-Desctructible Environments?

WOW! Now THAT is what I'm looking for in a game! I don't even mind the occasional growth (I'm guessing something to do with toggling a change using the binds), or even the temporary freezes (Red Faction had these to a good degree on rocket explosions too).

Ah, so you modified the heightmap brush to work on walls too! Very awesome! So is the remip and rebuilding of the level for bullet necessary (especially so frequently)? I mean, I remember 16 or so players shooting and editing all at the same time on a reasonably large map about a year ago (?), and I saw hardly any slowdown except when making large buildings at once with huge shadows.

Could the optimizations be done much less frequently, maybe progressively and slowly? Maybe if localized optimization only, call the optimization at the point of impact of the projectile only (or where the cursor is initially pointing when shooting), and only within heightmap brush range (instead of scanning the whole map).

May the Godess of Boredom shine on all and, inspire them to do things like this!

Last edited by MajorLunaC (2015-10-13 18:49:43)

Offline

#14 2015-10-13 18:56:05

chasester
Member

Re: Idea: Pseudo-Desctructible Environments?

look at the source code, i couldnt figure it out mostly cuz i was just testing a prodotype, but:

in octaedit.cpp
...
namespace hmap {
//all the hmap code is here, you can get anything to do what you want by just simply changing the way this edits the voxals.

void run(int dir, int mod) {
...
//all the magic happens here
// more or less the first part of this function determinds what are the bounds of the editing area (by using the selinfo sel;  and the gridpower, gridsize variables.

// the second part of this sets up a new selinfo called hmsel (idb) it basically forces all of the hm controls to happen only in this space and no where else, allowing for more control over the hmapped area (you could set a material call destructable and just simply if the mode is not editmode then limit any changes to only happen inside the bounds of this material, all other voxel would not have to be touched.

in octa.cpp
...
remit(){
//this is the command where you need to heavily modify to speed up the preformance of recaluation of the map, I suggest a module reload of the map, so set a timer allow it to work for said time, save the work and then wait, then continue this over and over until the map is finished. Then just simply replace the copy map data with the current map data, since this is a pointer you can just switch the memery locations, and delete the old one. Maps are farily small memory size so having 2 loaded at once should be no problem.
}

physics will automatically update if you are using cubes physics so no need to worrie about that.

Yes idb that hmapping works in multiplayer, but the mode must be editmode since the player goes into edit mode to make this change, tho im not sure if it ever tells the servers the edits its made, There is a better way to do this so if some one wants to write the rest of the code the server write around should be easy.

Ok final thoughts:
I am very interested in the concept of destructible terrain, (mainly cuz about no games have this done correctly yet and very few engines are even capable of the concept). But for me this is a very low end feature that could be explored later, my current mod of angel script/ bullet/ new entity system, would do leaps a bounds for the engines sp and mp expansiblity, so this is a higher priority. So if either one of you guys want to work on this, that would be awesome, and i think that would be an awesome feature to add. If you have any question on specifics of classes or functions, or where exactly to start I could definately give you a good idea.

chasester

Ill leave you with the exe and the saved.cfg (you need both for this to work)
Simpily right click then left click to shoot.

exe

Offline

#15 2015-10-13 19:43:31

gaya
Member

Re: Idea: Pseudo-Desctructible Environments?

I believe that getting something just like minecraft or this old Cube2 mod: https://www.youtube.com/watch?v=dKng8p4YNlM

Can be very helpful for people working on the engine. I mean, it's the basics: clearing the line between play and edit mode. If we get rid of that line, then the possibilities for modders are endless.

http://tesseract.gg/forum/viewtopic.php?id=281

Offline

#16 2015-12-22 22:22:58

gaya
Member

Re: Idea: Pseudo-Desctructible Environments?

Has anyone attempted other approaches yet? :)

Offline

Board footer