 |
I currently see two ways: 1) Enable interactions for the current decals (idRenderModelDecal, which is actually not derived from idRenderModel). The problem here is that interactions will be cached as part of interactions with the owner entity, which is usually static. So one has to hack frontend to force regeneration of interactions with owner whenever that is a decal on it. 2) For every decal, create a separate idRenderEntityLocal which represents it. This involves some lifetime management (store links, delete decal REs when owner RE dies). But then frontend should work out of the box, and interactions too (basically everything should). The model should probably be DM_CONTINUOUS, so that it can regenerate alpha every frame. This might also be more costly performance-wise... |
|
|
Here are some generic changes: r11021 Renamed idRenderModelDecal -> idDecalOnRenderModel, idRenderModelOverlay -> idOverlayOnRenderModel. r11022 Optimized Bvh build slightly. r11023 For two-sided material with interactions, make sure to set ID for duplicated surfaces. The last fix is quite critical: I won't be surprised if previously two-sided material randomly stopped working. And here is the implementation of the feature: r11024 Implemented projected decals which can generate interactions. r11025 Force using decal models with interactions by default. As of now, the new decal system is force on by default. If we discover some issue with it, we'll use both system depending on material flag. If not, then I guess material flag "forceInteractions" should be deleted. |
- Anonymous
