Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: m!m on October 11, 2017, 09:01:25 am
-
Apparently there has been a decal implementation in FSO before but that got removed again for some reason. This new decal system should work better and more importantly should work for the foreseeable future. This new system is based on our deferred renderer infrastructure which makes it very easy to render decals onto arbitrary geometry. Here are the test builds: http://swc.fs2downloads.com/builds/test/decals/
Typically these decal system would also allow to change the normal data of the surface where the decal is created but due to the way the rendering engine of FSO works at the moment that is not possible to implement. Once this initial version is integrated into FSO I will take a look at how the engine can be changed in order to allow normal mapped decals to be implemented.
The integration of the decals into the engine is quite limited at the moment since I first wanted to actually have a working system before adding more elaborate features. The builds introduce a new decal table type. There is no main table so you have to use modular tables that are named <something>-dcl.tbm. At the start of the table you need a #Decals and terminate that with #End at the end of the file. After that you can add as many decals as you like with $Decal.
After $Decal you need to specify the name of the decal definition e.g. $Decal: TestDecal.
+Diffuse: This specifies the texture or animation that should be used as the color channel of the decal. Currently there is no other channel but more features will be added in the future.
+Loop: This lets you specify if the animation should reset once it reached its last frame or stay on that last frame.
The only option currently supported is +Diffuse which specifies what diffuse texture should be used for this decal. This may be an animation.
Here is a complete table that I used for testing:
#Decals
$Decal: TestDecal
+Diffuse: ExpMissileHit1
+Loop: False
#End
To use that decal as the impact decal of a weapon you need to add $Impact Decal after the location where the engine expects $Shots:. You specify both which decal you want to use and how big the decal should be in the game world like this:
$Impact Decal: TestDecal
+Radius: 20
+Lifetime: (1.0 5.0)
+Lifetime specifies for how long the decal should stay around after being created. You can specify the range of possible values by using two values. The lifetime of each individual decal will then the chosen within that range. You can also specify the string "Eternal" (I'm still searching for a better term here so let know if you know one) if the decal should never vanish. This should only be used for very important effects since every decal uses some performance so too many will cause FPS issues.
As soon as that weapon hits a ship (it only works for ships at the moment) it will spawn the decal. The decals do not expire at the moment so performance will probably suffer if too many decals are created.
Please let me know if you find any bugs and while you are here, please let me know how this system should be integrated into FSO.
-
I'd like to test, if you could add the soundsets to this build.
Because my sounds.tbl is already too far mutated now, to use build's that don't have it :p
(so close to adding dlc to the game)
-
And one day......geomod.
#holygrail
-
I'd like to test, if you could add the soundsets to this build.
Because my sounds.tbl is already too far mutated now, to use build's that don't have it :p
Here are your special builds: https://www.mediafire.com/file/t3kw3w1c8i949x6/specialSpoonBuilds.7z
I changed the syntax of $Impact decal a bit so now it needs to look like this:
$Impact Decal: TestDecal
+Radius: 20
And one day......geomod.
#holygrail
Uhh, I'll let other people implement that because that's actually hard to do... :warp:
-
Crashes a the start of a mission with normal build, with a debug its crashes when firing:
(https://ibin.co/3dSBzsJi99eM.png)
-
I just encountered something similar to that myself. I'm not sure why that suddenly happened...
-
Does it work on beams yet?
-
No, it only works on weapons right now and beams will be very hard to implement since they move across the surface of the target so a single decal will not look right.
-
I think I fixed the crash described by Spoon. The builds in the first post have been updated. Those builds also include the sound set changes.
-
(https://ibin.co/3dfuvEPddjV8.png)
Well, it doesnt crash anymore at least.
-
:banghead: I forgot to remove the debug code from the shader again but at least that shows that the decal rendering is working correctly. The builds from the first post have been updated and should now render the correct textures.
What GPU are you using? I could only test this with AMD hardware so I would like to make sure that it also works with Nvidia and Intel.
-
Geforce GTX760 here
(https://ibin.co/3dh3MXNxNuS6.png)
Can truely produce works of art with this
There should probably be some degree of culling, be it life time or maximum number of decals. Possibly defined per $decal?
-
As I mentioned in the first post, this is mostly a tech-demo for testing if the decal rendering works reliably. Since rendering the decals seems to be working now we can discuss how to integrate the decals into the engine properly.
I will definitely add a maximum life for most decals but I would also like to add support for "permanent" decals which would also have better integration with the rest of the engine, e.g. by adding scripting access to these permanent decals. Another feature that could be useful could be time based scaling of the decal radius. If the decal is supposed to simulate a burning hull then it could be scaled down the longer it is present until it is gone completely.
I would like to avoid having a maximum number of decals since removing old decals would introduce ugly effects when a decal suddenly disappears.
-
I added support for specifying the lifetime of a decal and added documentation on how to use that to the first post.
-
The original decal system was of a black charred spot with a fuzzy edge and transparency. I also believe that it was discussed using a glowmap to give a burn glow, that lasted only a few seconds after impact.
-
(https://i.imgur.com/7xOhHtg.png)
Looks ok on nvidia :p
(https://i.imgur.com/0nrVWrp.png)
On Intel on windows not
-
The original decal system was of a black charred spot with a fuzzy edge and transparency. I also believe that it was discussed using a glowmap to give a burn glow, that lasted only a few seconds after impact.
Since you can use any texture you like with the new system this should already be supported by using an animation appropriate for the effect.
<snip>
On Intel not
Thank you for testing. Unfortunately, I have no easy way of debugging this with Intel so until I find a way to reproduce this somehow I won't be able to fix it.
-
Well atleast, Intel and Nvidia on Linux works. ;)
-
That's good! I can blame the Windows driver since the hardware obviously supports it if Intel works :p
-
The original decal system was of a black charred spot with a fuzzy edge and transparency. I also believe that it was discussed using a glowmap to give a burn glow, that lasted only a few seconds after impact.
Since you can use any texture you like with the new system this should already be supported by using an animation appropriate for the effect.
Would need an function to define if the animation plays only once or loops though. A looping fading glowmark doesn't look so great.
-
Good point. I'll add support for specifying if the animation should be looping or not.
-
Good point. I'll add support for specifying if the animation should be looping or not.
:yes:
-
That's good! I can blame the Windows driver since the hardware obviously supports it if Intel works :p
Probably because they're using the default WHQL driver. Intel users playing FSO should probably try to get their drivers from the intel website itself as those always have a bigger feature set than the WHQL drivers.
-
I don't know how the Intel driver situation is on Windows but the screenshots by tomimaki look like there is something going wrong with the shaders so I guess that even the non-WHQL drivers won't work properly.
The builds in the first post have been updated and should support specifying whether the animation should loop or not. I have added documentation for that option to the first post.
-
I tried driver from Intel website but no change.
-
I rebased the decal changes onto the latest master and the builds in the first post have been updated. I tried getting the decals to work with nebula environments but unfortunately I have not found a good solution for this which does not require extensive changes to the FSO rendering engine. For this reason, I chose to disable decal rendering when the mission is in a nebula. Obviously that is not the best solution but it is better than delaying this feature until I find a better solution for handling decals in nebulas.
I will open a pull request with these changes shortly so if you want something changed then now would be a good time to let me know :p
-
Do slash beams leave glowing decals behind their path now? ;7
-
No, I haven't changed anything from the last test builds and beams are going to be pretty annoying to implement so it will probably take some time until you can have decals from beams.
-
https://pastebin.com/n8xhVCPq
ASSERTION: "decal.object.objp->type == OBJ_SHIP" at decals.cpp:393
Only ships are currently supported for decals!
I've been running into this crash when using a weapon that has a decal. Commenting the decal part of the weapon entry out, seems to prevent this crash from happening.
I'm not entirely sure under what exact conditions this crash happens, since I've been using this weapon in other missions before without noticable issues.
-
I don't know how that assertion could ever be hit :confused:
Is this specific to one weapon type or does it happen with all decal enabled weapons?
-
I only ever got around to giving this one weapon decals, So I don't have an answer to your question, unfortunately.
$Name: Maser Gun Mod IVB
$Alt Name: Maser Gun
+Title: XSTR("Maser Gun Mod IVB (Medium)", -1)
+Description:
XSTR("Effective range: 1400
Damage type: Energy
Damage: 5-30 vs Hull, 5-20 vs Shield
Rate of Fire 0.35 - Cycle | Power usage 0.8", -1)
$end_multi_text
+Tech Title: XSTR("Maser Gun Mod IVB (Medium)", -1)
+Tech Anim: none
+Tech Description:
XSTR("Maser weapon technology has been experimented with for years, but never managed to find much popularity. The Maser atracts nearby ether in its flight path, increasing the amount of energy it will discharge on the target. Making the weapon destructive at long range but weak when used at point blank range.", -1)
$end_multi_text
$Model File: none
@Laser Bitmap: 2_laserglow03
@Laser Glow: glowLaser
@Laser Color: 20, 150, 45
@Laser Color2: 255, 255, 255
@Laser Length: 5
@Laser Head Radius: 0.2
@Laser Tail Radius: 0.2
$Mass: 0.05
$Velocity: 800
$Fire Wait: 0.35
$Damage: 5
$Damage Time: 1.25
+Attenuation Damage: 30
$Damage Type: Energy
$Armor Factor: 1.0
$Shield Factor: 0.67
$Subsystem Factor: 1.0
$Lifetime: 1.75
$Energy Consumed: 0.8
$Cargo Size: 0
$Homing: NO
$LaunchSnd: 339
$ImpactSnd: 87
$FlyBySnd: 263
$Flags: ( "player allowed" "cycle" "Particle Spew" )
$Icon: wi_mazer
$Anim: wa_mazer
$Impact Effect: MazerImpact
$Muzzleflash: Gmuzzle
$Pspew:
+Type: Helix
+Count: 1
+Time: 20
+Vel: 0.35
+Radius: 0.3
+Life: 1.0
+Scale: 10
+Rotation Rate: 1
+Bitmap: particle_green
$FOF: 0.001
+FOF Spread Rate: 0.015
+FOF Reset Rate: 0.15
+Max FOF: 1.5
$Impact Decal: Burnmark
+Radius: 4
+Lifetime: (4.0 4.0)
#Decals
$Decal: Burnmark
+Diffuse: capflash
#End
I can reproduce the crash fairly easily on further testing. It basically always seem to happen when this weapon is being fired into a ship that has just exploded. I recorded a webm:
https://www.dropbox.com/s/ma9g6cg1ueu69gy/Fs2_open_Wings_of_Dawn-EX15-SSE%202018-11-07%2018-55-25-91.webm?dl=0
The crash happens when the vid stops. As far as I can tell, it doesn't really seem to matter what ship type is being destroyed. Can also reproduce with a fighter for example.
-
Ok, I was guessing that it had something to do with how the engine handles debris.
I'll have to do some research to determine when and how the engine changes the object types of ships that are exploding. The easiest solution would be to simply check the object type but I would like to have a better solution that fixes the root cause.
-
I have submitted a small pull request (https://github.com/scp-fs2open/fs2open.github.com/pull/1927) which will track the original object type and mark decals as invalid if the object type changes. This will also output a log message when this happens which may make finding the actual source of this bug easier.