Editing material corners feature

by Q009 on 05/09/2008 15:26, 14 messages, last message: 05/12/2008 11:45, 1606 views, last view: 05/04/2024 18:05

Hi!

I thing Sauerbraten in next edition should have a corner modifing on materials like on normal cubes. It will be helpful.

   Board Index   

#1: material / octree

by MeatROme on 05/09/2008 15:41

This has been requested a number of times already; there are technical reasons for it not happening - the way materials are handled by the engine does not readily allow for non-full cubes.
Not that I don't also see the need for them or rather benefit this would bring mappers - especially water/lava (just think of a small brook murmuring downhill).

I think the most popular answer to-date is to try and handle such intricacies via mapmodels ... which, of course, doesn't help the majority of mappers all that much :-/

Regarding the non-stickyness of the "Requested Features"-thread ... I bet Aardappel didn't want all these to now become threads of their own ... but wasn't that kind of predictable? :-P

reply to this message

#2: Re: material / octree

by Quin on 05/09/2008 16:35, refers to #1

Maybe thats why it was there..

reply to this message

#3: Re: material / octree

by Q009 on 05/09/2008 18:02, refers to #1

Heh. I thing it needs only some code lines... =\

reply to this message

#4: Re: material / octree

by tentus_ on 05/09/2008 18:22, refers to #3

No, you're just wrong.

It would require a massive rewrite. Please familiarize yourself with the contents of the octa, material, water, and world .cpp files, as well as the .h files, before making baseless assumptions like that. The material system we have works as well as it does because it is limited to perfect cubes. Deforming them would be an exhausting process to develop, from what little I can deduce from the previously mentioned sources. I can't even imagine the bugs that would spring from the conversion.

reply to this message

#5: Alternative?

by tman_elite on 05/10/2008 00:50

Maybe, then, we could have transparent or semi-transparent textures for normal cubes. I'm not sure if it's possible now, and if it is it would be an alternative to glass (you can shape it any way you would a normal cube. I doubt this would help with things like lava or water, but at least you could make glass objects.

reply to this message

#6: Re: Alternative?

by a~baby~rabbit on 05/10/2008 03:42, refers to #5

Maybe if people gave concrete examples demonstrating a real need for what they would like to construct (with sloping materials) - as there may be existing alternatives or totally different solutions...

reply to this message

#7: Re: Alternative?

by SheeEttin on 05/10/2008 04:50, refers to #6

Downhill water, sloped clip, shaped glass...

reply to this message

#8: Re: Alternative?

by Gilt on 05/10/2008 05:23, refers to #6

... partial noclips, vacuum pockets... for example I'd ideally like to be able to deform an air material to create a vacuumous void that will suck the player towards it and tenderly asphyxiate them

reply to this message

#9: Re: Alternative?

by tentus_ on 05/10/2008 06:20, refers to #5

The problem with semi-transparent geometry is clipping. Anything that can potentially be seen through cannot be used as an occuller, so the one of the big appeals of geometry over mapmodels is lost.

I'd be all for sloped water and glass at a 45 degree angle, but realistically, they're nightmares. The code would be nasty, and we haven't even really touched on the subject of editing. How would you slope water without editing the geometry coexisting with it? The only thing I can think of would be that water containing geometry could not be sloped, which means that mappers could have to be careful and make sure to use the smaller gridsizes to bevel things out.

reply to this message

#10: ..

by Gilt on 05/10/2008 06:42

seriously though, that this 'feature' keeps on being asked for is simply due to bad design on our part.

technically speaking, materials are the negative space of a cube. it makes no sense to 'deform' a negative space in any way other then by deforming the matching positive space, the cube.

our 'mistake' has to give the negative space its own form. this affords the type of thinking that leads to silly questions like why can't I deform negative space like I can deform the positive space?

a similar effect occurs with cube editing: we enforce a convex constraint on cubes for performance reasons relating to collision detection. In a previous cube format, cubes used the edge info to build planes that intersected to produce the verts. The current method sees edges much more like the direct vertex coordinates. The end result being that with the previous method you couldn't really build an invalid concave cube, but the new method is more powerful and allows that opportunity (which we have to stop)

The funny thing is that the previous method feels a lot more powerful and easier to use, despite not actually being so: it never abruptly stops you from making a cube you feel should have been legal. it doesn't tease the user

If you actually look at the features being requested (sloping water etc), they're pretty much gimmick stuff that most other games don't use, even if they have the ability to. The problem is that by adding and presenting materials in the way that we did, we teased people into thinking they want those other stuff.

That's what happens when you tack on features without being able to provide a completely consistent interface; you make them aware of what they don't have. It's almost better to not tack on the feature in the first place.

reply to this message

#11: Re: ..

by Captain_Ahab on 05/10/2008 18:05, refers to #10

If a material is a negative volume of a cube, then would it be possible to make an invisible/noclip positive volume of a cube to define the material's shape?

there are other things I'd rather see for water anyways.

1. prevent monsters from having a line-of-sight through the water/air interface. ( for sharks and sneaking past sentries )
2. Use particles to make bullets, etc. throw up splashes when they enter water and then cut damage by some amount. Explosions would not be affected.
3. a way to simulate the raising or lowering of water/lava levels during play. ( deathtraps and drains )

reply to this message

#12: Re: ..

by Gilt on 05/10/2008 20:00, refers to #11

sure that would be much more feasible then the OP request. still doesn't answer the question of whether your asking for it because you actually want it, or just because you think it should be possible.

For example, what do people actually mean when they ask for sloping water? Are they looking for the surface effects? The volumetric effects? The physical effects?

If you have water that slopes at 45 degrees but does not push you downhill... is that really any better? would that not just be teasing people even more?

How about waterfalls? waterfalls have fundamentally different properties then a standing pool of water. You should not be able to leisurely swim up a waterfall in the same way that you can leisurely swim in a pool of water. It makes absolutely no sense to use the same material for both.

At the end of the day, if you want surface effects, then you want models/particles/etc. If you want physical or volume effects then you want materials. From a user design pov, one could say we messed up when we added surface effects to materials since that ultimately leads to a cognitive dissonance for users.

reply to this message

#13: Re: ..

by Captain_Ahab on 05/10/2008 21:19, refers to #12

I am not asking for it...just putting an idea up in the air...

I think the surface effects are more important as my sorta wishlist might imply. The main way water should affect things is from the surface/air interface, but that doesn't seem to be the case in the game.

Besides, too many things hurt framerate on my old machine anyways. ( old dual xeon IBM, 76oogs in an ancient agpX2 slot, 512 pc800 rimms )

Eh...except for surface effects concerning LOS or LOF...leave water as it is.

reply to this message

#14: ..

by IllvilJa on 05/12/2008 11:45

Ok... more trading of ideas.

One thing ticking in the back of my mind when reading the source is how to implement a model where cubes are not containing only two kinds of "content": the cube itself (which have six deformable sides each with it's individual texture) and the negative space (what's left of in the cube space) which as far as I understand it is the "material".

What I envision instead is this: Every cube contains a number of shaped entities (the only shape supported today by Sauerbraten is the deformable cube we all know, but future addition/enhancements to that are possible for those who dare to implement them) where every shape has it's own material: solid matter (like the deformable cubes today), air, water, lava, clips, thin (see through) mist, thick (totally obscuring) mist,dense vegetation, fire, gravity fields, AI Clips, mud (light players walk over it, heavy players sink down and get considerably slowed down) etc.

These materials do have a priority order (dynamic or hardcoded in the engine) which is used when determining what is present at a specific point when mutualyl exclusive shapes are overlapping. An example of the latter: air, water and solid matter are all mutually exclusive (a point in the cube can at most contain ONE of them) whilst shapes like AI Clips can overlap with shapes of water, thick vegetation etc.

Of course, one could give air material the least priority, so one could get away with letting the air having a simple shape that occupies the entire cube it is present in (the simple word for that shape is "voxel", correct?).

One VERY concrete example of where this would be useful is to create a shoreline which is NOT aligned with the octree planes but instead more freeform (within the limits of the deformability of cubes of course): a cube which contains a part of the shore line will contain three shapes of matter: solid (the rock that the landmass and sea bottom is made up by), water (the waterbody itself) and air (the air above the water).

I know, this would require rewrite of code with all the associated development effort (writing actual code, identifying and eliminating bugs etc) but it's one of the features I've got on the list of things I would like to look into implementing (a list which is too damn long already).

A note on the "thick vegetation" material for shapes: I'm viewing this engine and how to develop and enhance it from a "Battlefield 2" perspective and one of my main gripes about Battlefield 2 is that there IS thick vegetation which you can move through and in which you can hide but their implementation have a major issue: when close to the vegetation, you see it as a lot of grass etc close to you (which effectively obscures your sight out of the vegetation) but when sufficiently far away from the vegetation, the game optimizes away the vegeation so it is not rendered at all! Which means, the person hiding in the vegetation cannot see out, but the enemy who he is hiding from can see him perfectly (as the enemy see no vegetation!). This leads to the perverse practice that some players LOWERS the level of detail to make the graphics engine optimize away more vegetation, making it even easier to see enemies who tries to hide in the vegetation (and who think they actually ARE hiding).

The thing I wanted to implement were to have a "thik vegetation" material which instead of disappearing when being viewed at a sufficiently long distance does become completely opaque (but with appropriate texture for vegetation of course). When viewed at closer range, the material becomes less opaque (e.g, it can become a few layers of polygons all textured with an alpha layer (sp?) which makes the polygons partially "see through"). That way, by resorting to lowering the level of detail, one does cause the game engine to render more of the vegetation as "totally opaque", that is, makes life easier for those who are hiding in said vegetation.

(Then of course, as this is a "Battlefiled-like" feature, hiding in the vegetation will only conceal you, not protect you from enemy bullets, or grenades, or artillery shells, or airplanes dropping napalm over the entire field etc... you get the idea)

Another reason I want to develop this feature is that it helps us to get away from the situation where the octree cubes interferes with the map design, that is, forces features on the map to be aligned with the coordinate axis. To put it in another way: the octree is a good servant but not necessarely a good master.

reply to this message

   Board Index