Jump to content
The Dark Mod Forums

SteveL

Active Developer
  • Content Count

    3666
  • Joined

  • Last visited

  • Days Won

    62

SteveL last won the day on November 3 2017

SteveL had the most liked content!

Community Reputation

1041 Deity

About SteveL

  • Rank
    Hero Coder
  • Birthday 05/28/1974

Profile Information

  • Gender
    Male
  • Location
    UK midlands

Recent Profile Visitors

745 profile views
  1. That's right. 2 stages are the same as 2 materials. In theory it's slightly faster to draw a model twice in a row than to draw 2 models. But I doubt anyone will ever notice. I tried to "break" the renderer by multiplying these things up enormously in test maps without ever making much difference. General scene complexity and shadow complexity is much more important than optimising any one feature like tri counts or draw calls on a model. My best advice is to be aware of what makes for good performance and work with it but not worry about it otherwise. Everything else that happens in a real map will completely drown out the effect of trimming a few thousand tris here and there.
  2. Suggested test for your 500 tri model if you still have questions for it: Put it in a simple caulk box room so there is nothing to be drawn but the model. No visportals or walls obstructing the view.Add an ambient_world light covering the map (if you try to use no ambient_world, the game will go ahead and generate one for you so you might as well place it yourself so you know for sure where and what it is).Add a simple light covering everything and a trigger to turn it on and off every second. (EDIT: or not, see below)launch the map, kick off r_showprimitives 1 and con_noprint 0 then close the consoleYou should now have a constant amount of console text on screen. The difference in tris as the light turns on and off should be the tris of your model.I'm not sure off hand whether model tris facing away from the light will be counted. There are so many optimisations in the engine that there's often a long explanation for the exact tri count. The engine has various ways to exclude parts of your model from being drawn, some of them in the engine itself (which means the tris won't be counted by r_showprimitives) and some in the GPU (which means the tris still get counted as "drawn", but they won't use up much GPU power as they don't get coloured in). EDIT: You probably don't need a trigger come to think of it. Simply facing away from the model will be enough to stop it being drawn as long as you are a little distance away (so not in its bounding box).
  3. There's a certain base tri count that you will never get rid of. The HUD generates tris to be drawn. The biggest culprit is the console: every character shown on the console is 2 tris, and they do show up in the tri count. A console full of text is worth about 1500 tris if I remember right. Also the lightgem, and a few other things generate a handful of tris. I always found that irritating in my renderer test maps. I used empty maps, no skybox, everything made of caulk except the one thing I wanted to test but the console tri counts varied by more than the thing I was trying to count!
  4. Is it md3_water_test_refraction you're using? There are a couple of variants in that material file but I think that's the one.... But I can't see (yet) what is causing the brighter posts and hull below the waterline. The only light being added in that material is from the specular highlights on the water. Are you using any other effects in the screenshot above? Like fog lights, or another material on a patch beneath the surface?
  5. Any light hitting a surface will cause its tris to be drawn again. Lights with multiple stages count as multiple lights, but we don't have many of those (if any). Fog is only considered "expensive" because of the relatively small effect that it gives for the cost. It's cheaper than other light types because it uses a very cheap shader: it just adds some static colour to the tris that it hits, so it draws the tris again but it doesn't use the surface's diffuse, bump, or specular maps to do any complex shading which is what normal lights and ambient_world do.
  6. Can you link the water shader you are using? Or is it packaged with the mod now? I remember both Arcturus and Obsttorte did clever things with bumpmapped transparent shaders but I'm a bit behind on latest developments I'll have a look how it works and see whether we can get the best of both worlds.
  7. Cool. Feel free to post a line of code if you want any help. You can't use quotation marks in the text to be displayed, but it'd look something like this: $messageEnt.setKey("spawnargName", "You have " + myFloatVariable + " widgets");
  8. Since you're already using a script, try using $messageEntityName.setKey() to put your variable's value into the spawnarg that holds the text to be displayed.
  9. Scripts can use setShaderParm() to do this, and the material can set alpha using parm3 (or whichever). It'd also need the translucent keyword, and I don't think it would cast shadows unless your model has a shadow mesh. Edit: I don't think this will work, on second thoughts. Translucent materials are drawn as an additive blend and they ignore the alpha channel. You could do it as a custom blend material, but it wouldn't be lit it'd be fullbright.
  10. Cool. I added a fix to the script above by the way by moving chest.setKey("already_opened", "1"); to the top of the block, so the player can't trigger the script a second time during the sys.wait()s between multiple items being spawned.
  11. Ah, that's a "state_change_callback" script. @kingsal You could use one of those more simply than a script object to get the job done with the chest. state_change_callback is a way to call a script when a door is moved or a button is pressed. Unlike most ways to call a script, the script gets told which entity fired it. Chest lids are doors, so you could put your spawnargs on the lid along with "state_change_callback" "autoloot_chest" Then in your map script: void autoloot_chest(entity chest, boolean bOpen, boolean bLocked, boolean bInterrupted) { // Fire only if map has been open 3 seconds (avoiding map initialisation) and // only the first time the door/lid is fully opened. if ( sys.getTime() > 3 && bOpen && !chest.getBoolKey("already_opened") ) { chest.setKey("already_opened", "1"); // Search through "random_spawn" spawnargs, and find a matching "random_chance" spawnarg string key = chest.getNextKey("random_spawn", ""); while ( key != "" ) { float chance = chest.getFloatKey(sys.strReplace(key, "_spawn", "_chance")); float r = sys.random(1.0); if ( chance > r ) { entity newItem1 = sys.spawn(chest.getKey(key)); newItem1.addItemToInv($player1); sys.wait(1.0); } key = chest.getNextKey("random_spawn", key); } } } The script disables a chest by adding a spawnarg to it in real time. You can use any random_spawnXYZ spawnarg naming scheme as long as there's a matching random_chanceXYZ sparnarg for each. Without the matching spawnarg, the chance will come out at 0 so the item won't ever be added. I tested it with these s/args on a chest lid: "random_spawn1" "atdm:ammo_firearrow" "random_spawn2" "atdm:ammo_mossarrow" "random_spawnA" "atdm:ammo_broadhead" "random_chanceA" "0.5" "random_chance1" "0.8" "random_chance2" "0.5" "state_change_callback" "autoloot_chest" You can make a new entity def with your preferred settings. Then changing the def will change all matching chest lids that haven't overridden the spawnargs. If you want to stick to your original plan of a separate script for each chest then Spooks' global variable is the quick way as you found, but that method only works with a separate script for each chest, because a script shared between chests wouldn't know which chest had triggered it (and so couldn't disable the right chest).
  12. Have you re-dmapped since updating the materials? The keyword to make a material seal against the void is forceOpaque. It goes up top with surftype and description. You don't always need it, but the keyword will make even pure transparent blend materials seal. I've seen that borking mostly when messing with cubemaps, but I can't remember how I fixed it. It was something silly like re-dmapping.
  13. You could probably use the menu function that selects all entities that have the same model as the one you have selected. That'd let you skip between chests in the map easily. The script object version would also let you balance the loot distribution by setting a probability against each item so you could have the same spawnargs on every chest and still keep the loot balanced. e.g. "random_spawn1" "atdm:weapon_shortsword" "random_chance1" "20" I don't mind providing the starter script object if you want to try it out. The documentation is a bit brief, both ours and ID's.
  14. In theory I don't think it should make any difference whether you use dds or tga. Which material did you use as a template? The clue might lie in there. Quite a few TDM decals depend on blending tricks that don't use the alpha channel from the image file at all. Unfortunately I don't think it's possible to have proper alpha transparency on solid materials that are affected by lights, and you'd need these signs to be opaque and lit. Our lit transparent materials are all translucent, like cobwebs, water ripples and glass that add an extra layer of brightness to the background without blocking it out. Can you stretch the image to fill the quad instead? if you need a frayed edge you can use an alphatest material instead. The edge won't be as smooth-looking as an alpha-blended image, but it's a way to get a wobbly edge from a flat quad.
  15. Sorry, I was thinking of NHAT not A Night to Remember. I don't know about the problems with ANTR.
×
×
  • Create New...