Jump to content
The Dark Mod Forums
demagogue

Newbie DarkRadiant Questions

Recommended Posts

I like fireflies too and want to use them in my outdoor regions. I think in Alberic's Curse the fireflies are moving lights. At least the ones I've noticed high up in the trees.

One option I've found is to create my own fireflies in the Particle Editor for a func_emitter:

  1. Create a new particle with a single stage.
  2. Use shader textures/darkmod/sfx/fake_haze_01 and give it a color.
  3. Set "count" to 1, unless you prefer more fireflies at the same spot. Duration to something long, like 25 seconds.
  4. Set path to "helix", radial and axial speed to 5, and cylinder size X & Y to 20.
  5. Set speed 10, size 4 and gravity -0.1
  6. Tweak until it roughly looks and moves the way you want. Fake a light with a normal light if the fireflies remain roughly at the same position. Maybe bind the light to a func_bobbing entity to give it slight movement and make it a little more convincing.

For falling leaves it's the exact same thing, except with a leaf shader and a positive gravity number.

Another more crude firefly option I've tried is to bind a tdm_wisp particle to a light and two func_bobbing entities with x_axis 1 and y_axis 1 with a different phase each for movement.

For some reason, my wisp particles are always drawn behind water surfaces. I use a lot of water surfaces in my outdoor region, so I have to keep the wisps high up in the air and away from water. Waterfall particles are also drawn behind water and these need to be near water. I hope this bug will be fixed.

I hope this helps. If you find better ways to get convincing fireflies, please share :)

Share this post


Link to post
Share on other sites

Generally I think fireflies are just particle emitters (tdm_wisp or similar), but Alberic's Curse may be a special case: I can see MD5 files for fireflies in the /models/ hierarchy, apparently from the unreleased Blackheart Manor.

Also to my surprise, the falling leaf particles in Alberic's ocn_leaves.prt appear to have been made using blood materials instead of leaf materials. (Edit: but I'm unsure to what extent those were used, since there are also bkd_falling_leaves_*.prt files in there.) The Creeps also has falling leaves I think, using a custom material/texture.

Moving fireflies are probably spline movers: like this but with something other than a camera following the spline.

Edited by VanishedOne

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Share this post


Link to post
Share on other sites

It's better have a gameplay-driven excuse for using moving lights for fireflies, as they impact performance a lot. If it's just a neat-looking effect you want to have, stick to a static light with pulsing/flickering effect in the material definition.

Share this post


Link to post
Share on other sites

Different topic. I was unable to find is a way within DR to search for a particular object (to add to a map) by key word, ideally across the {entity, model, prefab} universe. (If it exists, please tell me where? Or this might be a new feature request [see below])

Maybe those of you on Linux use the op sys for this.

Along those lines, here's what I came up with quickly for Win10 (i.e., without writing a shell script or C# program). Win10 as native support to index .zip's, but not .pk4s. So I made a copy of the tdm_update_win directory (say, " tdm_update_win_search_copy") and renamed all the .pk4 to .zip (using the command console "rename *.pk4 *.zip"). You can then follow the procedure here to make sure .zip files are indexed and the search includes them:

https://superuser.com/questions/1252895/how-do-i-do-a-search-in-file-explorer-that-includes-subfolders-of-zip-archives#

Purging non-zip files and folders from tdm_update_win_search_copy will cut down on the false hits. Then you start your search within that folder. The resulting listing, while non-ideal, should be often good enough. A limitation is that the algorithm is just looking for a string within individual filenames (e.g., within each .zip container), so doesn't know about any descriptive text. (An ideal version within DR could offer that, and smart filters too. And maybe over time synonyms, support for topic tags, on and on...)

Interesting to hear about other solutions too.

  • Like 1

Share this post


Link to post
Share on other sites

Here's what I did. I took all of the .pk4 files from my \darkmod install, and unzipped them to a different directory, in this case c:\dm_all. (I use 7-zip, and it will extract multiple zips all in one go). So all of the pk4s are unzipped to a single folder hierarchy. If I'm looking for a file by name, I just use Windows search on c:\dm_all. But, if I want to search within those files, I use Textpad Find in Files functionality. I search the entire c:\dm_all folder hierarchy, limiting it to the following file types: *.vfp *.skin *.map *.pfb *.mtr *.def *.script *.sndshd *.prt *.xd *.lang *.gui*. It takes a minute, but that way I can find descriptive text, and also objects that are defined in text files. For example, let's say you are interested in atdm:ai_builder_priest_combatant. You won't find a file with that name, but if you search within text files you'll find that entity defined in the file 'tdm_ai_builder_priest.def'.

It's important to limit the file types because otherwise it searches through all of the graphics files which is a waste of time.

Anyway that's what I do. Maybe there's a better way.

Edited by joebarnin
clarity

Share this post


Link to post
Share on other sites

Nice approach, even if the more detailed search is slower as you said; it has more to search without the speed benefit of pre-indexing.

Share this post


Link to post
Share on other sites

There's also SteveL's keyword/regex search script.

Within DR, you can search listings of models, materials, etc. by just typing while you have a list item selected, then use the up and down keys to move between results. How well it works depends on how many results you end up dealing with.


Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Share this post


Link to post
Share on other sites

It's great to learn about the DR method, VanishedOne. Even though it's limited to a particular list type at a time, and - as you note - the up/down approach to results can be tedious when hits are bountiful.

I wonder why the search box is kept hidden until you start typing. There's ample space (say, in the header) to keep it visible, and doing so would then advertise the feature's existence.

Share this post


Link to post
Share on other sites

The DR method doesn't work for me on Ubuntu 19.04 with DR 2.6.0 x64. When searching for models etc by typing, the search box does appear when typing and the first deep nested map opens up for the first letter I type, but the list doesn't respond to any text changes in the search box after that. The up and down keys do nothing.

Unpacking the pk4 files is a good idea, I hadn't thought of that. I've just been scrolling around and taking notes of useful file locations and names. Thanks!

Share this post


Link to post
Share on other sites
On 8/5/2019 at 8:46 PM, Jedi_Wannabe said:

How do you make convincing fireflies, both sitting still and flying around?

BD had some good ones in Alberic’s Curse, also how’d he do those falling leaf particles?

Do I use emitters?

I would use a particle emitter for that, then just tweak it so it looks like they are randomly flying around.  But if the TDM team wants to code a special "boids" system that would be awesome.  ;)

Boids system

Share this post


Link to post
Share on other sites

I'm about to release a new mission, but I've got a performance issue that I'd like to resolve. I've got a building with a torch light on the outside wall. The light is causing performance issues inside the building, even though the wall blocks the light from getting inside. On the interior surfaces, the shadowcasting calls ('shdw' when doing r_showprimitives) are high. If I extinguish the outdoor light, the shdw count drops way down, and "r_showlightcount 1" drops by one too (on the interior surfaces). 

Any ideas on how the light is getting through? It doesn't show as light - the walls (brushes) are blocking the light. But somehow the engine thinks the light is there. There's another building with the same kind of light on the outside wall, and it all works fine. I keep experimenting with the walls, but so far I can't figure out what the issue is.

Does anyone have any suggestions?

Share this post


Link to post
Share on other sites

You could try moving the light radius away from the interior and shifting the light center so it stays by the wall.  Or a more complex option would be a script that turns the light to noshadows when you enter the building.

edit:  Actually, have you tested for internal leaks?  If the light is in a visleaf that can't be connected to the player while in the interior, then the shadows shouldn't be calculated.

  • Thanks 1

Share this post


Link to post
Share on other sites

My first thought as well. If the light is sealed off properly by brushes and visportals, it just won't be rendered. It's either an internal leak or visportal not closing. You can use func portal, if you need to control it better (proximity based).

  • Thanks 1

Share this post


Link to post
Share on other sites

Springheel & peter_spy - Good idea. Today I checked to see if there were any internal leaks, and I didn't find any. I followed the technique described by Springheel in one of his videos. There were no obvious leaks.

I've spent a lot of time trying to isolate the problem, but every time I think I get close, it gets more complicated. Here's what I can say for sure:

  • The outdoor light contributes to the shadowcasting calls (and to the light count) of nearby interior rooms. Dousing the light brings the shadowcasting/lightcount down.
  • As far as I can tell, there are no leaks in visportals (or anywhere else).
  • If I isolate the interior room, so that there are no other light sources, then the problem goes away. That is, even when the outdoor light is lit, it doesn't contribute to shadowcasting/lightcount, but only if the indoor room blocks all other light sources.

I tried setting the outdoor light to noshadows, and that reduced the shadowcasting counts, but you could see the light through the walls (in the interior), which I guess is expected?

I've spent a lot of time trying to figure this out. I'm ready to release the mission - it is playable, but there may be performance issues in this room for certain hardware. It would be nice to resolve this, but unless someone has a brainstorm...
 

 

Share this post


Link to post
Share on other sites

Yup, setting light to noshadows works correctly. If visportals work correctly and there are no leaks, you can try setting up a func portal to see whether they're closed when player is outside. A lot depends on where the door opening is, but just for testing purposes, you can set it to very small value. http://wiki.thedarkmod.com/index.php?title=Visportals#Visportal_switches:_func_portals

  • Thanks 1

Share this post


Link to post
Share on other sites

The advice people often give in this situation is, when you really can't find the source of a problem, you just clear the problem area or brushes and re-build it from scratch with a very clean building style. If you can track it down to a small area, then that's not so bad, but if it's a larger area, that might be more effort than it's worth, especially in your case of otherwise being on the verge of release. 

  • Thanks 1

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites
Quote

I've spent a lot of time trying to figure this out. I'm ready to release the mission - it is playable, but there may be performance issues in this room for certain hardware. It would be nice to resolve this, but unless someone has a brainstorm..

 

Did you move the radius of the light as I suggested?  You should be able to move it so that it doesn't overlap the interior room, and the move the light center so that it stays on the torch.

lights9.jpg

  • Thanks 1

Share this post


Link to post
Share on other sites
9 hours ago, demagogue said:

The advice people often give in this situation is, when you really can't find the source of a problem, you just clear the problem area or brushes and re-build it from scratch with a very clean building style. If you can track it down to a small area, then that's not so bad, but if it's a larger area, that might be more effort than it's worth, especially in your case of otherwise being on the verge of release. 

I spend a lot of time this weekend trying to do this, without success. I probably wasn't as systematic as I needed to be. It's a fairly complex area to redo.

One thing I forgot to mention in my previous post: I did have some success in one interior room. The boundary between inside and outside consists of two walls, worldspawn brushes, each 8 units thick, adjacent to each other. As a test, I expanded one of the walls by two units, so that the two walls overlapped. E.g.:

walls.jpg.7d40a180d303c7cc2f301089b4ade7fb.jpg

In one interior room, that effectively 'blocked' the outdoor light - the shadowcast count dropped, and the r_showlightcount dropped by one as well. So, partial success. But this 'fix' did not work for other interior rooms.

Share this post


Link to post
Share on other sites
3 hours ago, Springheel said:

 

Did you move the radius of the light as I suggested?  You should be able to move it so that it doesn't overlap the interior room, and the move the light center so that it stays on the torch.

 

Shoot, forgot to try that. I'll give it a go now.

  • Like 1

Share this post


Link to post
Share on other sites

Eager to see the results joe!

One thing I was wondering, was this problem existing BEFORE the alterations to the VPs? Had you narrowed this issue down as being a contributing factor to the performance in the said interiors already? I guess my fear is, did I make a bigger headache for you?

Share this post


Link to post
Share on other sites
16 minutes ago, Jedi_Wannabe said:

Eager to see the results joe!

One thing I was wondering, was this problem existing BEFORE the alterations to the VPs? Had you narrowed this issue down as being a contributing factor to the performance in the said interiors already? I guess my fear is, did I make a bigger headache for you?

Nope, Jedi, you are innocent 😀. This problem has been there all along. 

  • Like 1

Share this post


Link to post
Share on other sites

This is a long shot if there are no other signs of light-bleed or internal leaks, but are there any non-opaque brush surfaces (like caulk or nodraw) in the problematic wall, including surfaces you can't see because they're flush with an adjacent brush?

(Caulk is opaque in a certain sense, but internal caulking has given me light-related headaches before. I sometimes use shadowcaulk for that reason.)

Edited by VanishedOne
  • Thanks 1

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Share this post


Link to post
Share on other sites
5 hours ago, Springheel said:

 

Did you move the radius of the light as I suggested?  You should be able to move it so that it doesn't overlap the interior room, and the move the light center so that it stays on the torch.

lights9.jpg

I gave this a quick test, and I'm seeing strange behavior. I created a light_torchflame, and offset the light_center, similar to your diagram above. First, the particle emitter is at the origin, not the light_center. I suspect I can figure out how to fix that. Second, the light that is cast has a few issues. There is light at the light_center, broadcast to the 'left'. But it uses the 'biground_torchflicker' texture, so it doesn't quite look right. The wall doesn't get any light, and I guess that's what is intended, but that looks incorrect too. Finally, there appears to be light coming from the location of the emitter. Not just the flames, but cast light.

Here's what it looks like. Light from the light_center shouldn't reach that wall.

light.thumb.jpg.f7539172b361432498aecd6925016981.jpg 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...