SabreCSG
SabreCSG copied to clipboard
sabresaurus
[Feature Request] Hide (Not Exclude) Faces
I often exclude faces for visibility purposes when editing, but this affects the lighting in some cases. Would it be possible to add an option to hide rather than exclude faces, allowing them to still create shadows? (Apologies if I've missed something obvious)
I have been thinking about visibility issues in general, even shown a suggestion here: #43 for dealing with the brushes. Could you show an example of when you'd want to hide faces? Perhaps there is a more elegant solution similar to the pull request above instead of having to manually select faces to hide and show them.
a simple room with an outside lightsource is a perfect example of wanting culled but still shadow-casting surfaces. if all the outside faces are excluded, the walls cast no shadows whatsoever.
Ah I see! So essentially we want to have a special ShadowMesh to cause this:
Which you could already achieve by simply setting the shadow casting property in the CSG Model to "Shadows Only":
We recently made all CSG Models use double sided shadows to fix a humongous amount of light leakage bugs. So your example may actually have proper shadows now. As he specifically mentioned visibility purposes I thought maybe he means something keeps blocking his view and he can't see what he's doing. But I suppose this may have other useful use-cases.
I can have a look and work on adding this feature.
jmickle66666666 is correct. To put it in other words. I'd like to be able to set a single face to "Shadows Only", rather that the entire CSG Model.
Like so:
If it's possible to add a "Hide" function, perhaps it'd make sense to place it next to the "Exclude" button:
I've been thinking about this, while we could implement the hide toggle you suggest it would be very case specific. What I think we should probably do instead is have the Polygon class support tags, one of which could be ShadowsOnly. Some of these could be built in, some could be user defined. The build process would then segment the polygons by tags (in addition to the material), applying special logic as appropriate - e.g. polygons with the ShadowsOnly tag have their renderer set to ShadowsOnly. By incorporating support for custom tags we also help users that want to tag certain polygons then use that tag for gameplay purposes (a common request is to support audio being different on a certain step).
This sounds very similar to what I told the sabresaurus in a PM. 😛
Let's learn from past mistakes:
Unreal Editor has had flags/tags since the very beginning and they stored it as a 32-bit integer. This means there was a maximum of 32 flags that could be set on a surface as seen in the image below:
The Invisible flag is essentially the discard tag we already have. You can use the U-Pan and V-Pan flags to animate the material horizontally and vertically respectively. One more example is the Unlit flag that would make a polygon ignore light and be fully lit.
Even though at first glance this is awesome there is a problem. Say you want to have the texture pan in the opposite direction, you can't do it, unless you flip the UVs manually. Say you want to adjust the scrolling speed, it can't be done. The developers eventually resorted to adding these parameters to zones in the game. So now if you want to have several textures scroll at different speeds you'd have to isolate them from the rest of the map (using invisible non-solid planes) to set these properties, a lot of work, a lot of bugs.
Quake 3 Arena provided different materials like caulk_nonsolid or misc_portal_surface that cause special things to happen. They resorted to placing objects very close to the wall to provide additional parameters, not a very nice solution either and similar to the zone issue.
Long story short: Tags should have the ability to define additional parameters.
I may be wrong and this is just speculation, but in Zelda: Ocarina of Time for the Nintendo 64 polygons had flags as well. One of the flags was marking a surface as Hookshot-able (the Hookshot is an inventory item, a chain that can pull you towards an object or some polygons in the level)
This brilliant the cutting room floor article shows there were several unintended polygons that received this flag for some reason. Or had the wrong type of sound like the sabresaurus suggested.
To me this means that visibility of the flags was an issue. This same issue exists in Unreal Editor. There is just no way to show what polygons have what flags.
Long story short: Tags should be easy to find, perhaps with a search bar, hiding all the polygons that do not have the tag or don't match a filter.
Quake's brushes have an arbitrary set of key/value pairs that are used for all kinds of data, a similar approach would probably be the wisest option. Since both the keys and values are just arbitrary length strings, they are used for everything from just settings a flag (a key with a value of 1, or just not an empty string), setting ints and floats, or even lists of space-delimited parameters (this is used for R G B color values for instance).
I do agree, that's a very dynamic option. But I personally found it hard to find all of the available keys and would spend a long time looking up documentation on all types of surfaces (or make the occasional typo). Alternatively it would be possible to create a C# class for each tag that has serializable fields that show up in the inspector. That would then allow a similar syntax to Unity components, for example:
Polygon[] FindPolygonsByTag<HideTag>();
Which would then have these additional inspector attributes available. Making it a lot easier for developers to implement their custom logic. We would find all tags in the project through reflection, like we do with all the compound brushes.
I think that the proposed tag system sounds very interesting, in particular if it can be easily user extended.
However, I feel it might be necessary to re-iterate my original issue, which was one of visibility while editing. Being able to see and edit the contents of enclosed spaces in the editor without affecting the lighting and shadows shouldn't be considered a special use case, it should be part of a normal work flow, IMO.
I don't think I'm alone in wanting this functionality. While perhaps a different beast, Realtime CSG's main mode of handling editing visibility is done in this manner and I think it's (quietly) appreciated.
EDIT: Accidentally closed the issue...
I created a quick solution for matte shadowing, using a combination of unity's built in shadows only options, materials, and the SabreCSG post build listener. The code for it is here.
You will need a material called "Shadow Caster". The case does not matter, but the shader needs to be a shadow casting type. Then to define what gets made into a caster, you simply assign the shadow caster material to any face of any brush.
Edited to fix some readability issues, and moved code (updated) to gist so its easier to edit.
