kingsal
-
Posts
1099 -
Joined
-
Last visited
-
Days Won
40
Posts posted by kingsal
-
-
@nbohr1more Hey thanks! I wasn't planning on updating this mission, but Ill definitely include this in the next ones and whenever I swing back around on this!
-
Ive seen this happen where the AI will be alerted during a conversation but wont take action until after the conversation loop is finished. This is usually from a build up of audio alerts. If they clearly see you they’ll usually stop.
Just a heads up conversations and scripts can get pretty messy. Ive experimented with this is my current fm and its seems like any functions called directly to the ai ($guard.moveTo() for example) will happen after the conversation is done and as Dragofer mentioned you can’t always depend on a conversation being done…
After my first mission I kind of learned to just design areas around conversations so there’s less chance of them being interrupted by the player. Making sure they start while the player has a good hiding spot, removing noisy surfaces and things the player might bump in to, and also trying to start the conversation before the player sees the AI so they don’t accidentally shoot them with an arrow or flash bomb them.
-
1
-
-
1 hour ago, MirceaKitsune said:
It would be neat if for starters we could allow DarkRadiant to export the top-down view to a transparent png, so mission authors can then include it without having to draw their own by hand.
Yeah I'm sure its possible. For automaps we'd want some kind of tool in DR where the author can "draw" or select areas, label them, and then export those out as gui images. Those could then get rendered as transparents on top of the current in-game map OR just be exported as entire map images. The author would also have to label all their locations correctly and we'd need scripts to drive all that. This exists in some form already, but it would take a lot of thinking and effort to truly automate in-game map creation.
-
I dont think darkmod needs a mini map. Its not really trying to solve any problem and goes against so much of what makes the thief formula work.
Although, I could see making better support for highlighted areas on the current in game map (this is possible now with some scripting but requires individual hand drawn maps for each change in area) It would be entirely up to the author to create the content for it and we would not be able to retroactively integrate it into current missions.
-
23 minutes ago, greebo said:
I figured most materials in TDM maps will be lit by sources that have a flame-like colour, so this resembles the final appearance best. But of course it doesn't offer a neutral view on the material which might be desirable too. I think remembering the value would be best, please feel free to open a tracker entry for that.
Thanks for the update man. Yeah I second going with something more neutral just a good ole 50-75 percent bright white light. I appreciate being able to see them in context though.
-
38 minutes ago, duzenko said:
You can't really expect other nationals to follow your cultural code just because you invented the Internet
Uh no, but we still have forum rules regardless. These seem pretty reasonable and universal.
-
1
-
-
8 minutes ago, peter_spy said:
After several pages of patient discussion, posting relevant links and referring to facts, which he ignored entirely, since his subsequent responses were still the same make-believe? Yes, unfortunately.
I think your missing the point. We don’t tolerate name calling and personal attacks regardless of how patient you’ve been.
Clean it up, be respectful.
-
1
-
1
-
-
1 hour ago, peter_spy said:
That said, I don't think it's about messing on purpose, it's just his MO. You've already seen it in multiple bugtracker entries too. He barges in, usually without checking wiki or forums on certain functionality, makes up his own ad-hoc interpretation of it, automatically assumes it is canon, and then it takes several people to explain him the "historical context", or that he mistakes bugs for features, etc. Then either he lets it go, or, if he is stubborn, he'll reply with walls of misinterpretation until the other party has no more energy for it.
And this is how you choose to respond ?
"You seem to have a peculiar cognitive disorder".
"...it stands for Level Of Detail, and not Lights Off, Dumbass."
Knock it off. This kind of language is destructive and harmful and has no place here no matter how much you disagree with someone.-
1
-
1
-
-
That is very cool and very impressive!
Right now it would be a lot of us to take it on for 2.10, but getting it in a mission would be awesome and prove out a bunch of stuff before going into the mod. I'll download this though and do some testing and play around with it when I get a chance.
-
1
-
-
11 hours ago, Dragofer said:
This was just some plain func_static wooden beams made out of patches, with a 'stuck' version of a broadhead arrow lodged in one of them. Only the beams had any kind of LOD, hide_distance, enabled.
Stuck arrows probably shouldn't be moveables anyway.
Interesting, stuck arrows are not moveables. They inherit a weapon_arrow_base which is its own special thing. I was referring to general moveables (crates and the like) will keep their collisions meshes even when their physical models are hidden. Although thats not to say there aren't bugs that could occur here.
I could see an arrow appearing and disappearing, but dropping to the floor is pretty odd considering they are bound to the entity they are stuck to. -
On 8/3/2021 at 2:33 AM, Dragofer said:
Seems odd that a visual performance optimisation makes the entities become nonsolid. I've got an arrow stuck in some LOD-enabled wooden beams and when the player is over 1500 units away the arrow drops to the floor.
That shouldn't be happening. Out of curiosity does the model or its LOD have a collision mesh? This won't happen to moveables AFIK since their collisions meshes are kept.
-
1 hour ago, MirceaKitsune said:
I believe last time I de-hardcoded the color from the particles and made common particle definitions.
The color is not hard coded into the particles, it comes from the texture map which then gets "tinted" by the entityColor argument in the .prt. So we need to create grayscale maps for all the associated particles, which I've already done. This method doesn't require explicit color defs like you have (red, green, blue, pink).
1 hour ago, MirceaKitsune said:I'm not aware of a way to propagate the color along a chain of attachments instead. Any thoughts?
Yeah so this is done with a "set _color on flame" "1.0 1.0 1.0" Basically telling attached object named "flame" to have _color set to 1 1 1.
Dragofer and I are looking into a method using the script object for light holders to colorize the FX and even model skins. This way *any* light object with an associated flame can be colored as well as the models glowy bits. Glowing candle wax or fire embers for instance
-
Having colored lights is a great idea! As Dragofer mentioned we are looking into ways to make this as customizable as possible.
I've made some progress and have colorable candles, torches, ect that will pass their color to their particle effects. I'm going to look into some other stuff and then I'll post up what I have. -
6 minutes ago, nbohr1more said:
OK, sorry to be a pain but I did ponder one other sort of ugly use-case.
The mission "Sir Talbot's Collatoral" uses many small and subtle lights referred to as "bounce lights" to improve the look of ambient lit areas. If some author went crazy with this lighting method, performance could be very bad in a large open area such as a warehouse, courtyard or foyer. Turning off these bounce lights at a distance would be far less noticeable since they only add subtle effect anyway.
I use a ton of bounced lights as well, even in large spaces. Its true they can really add up if you arent careful, but at least in my case turning them to noshadow is what keeps the frame rate from tanking
Also from my understanding its moreso about the amount of surfaces those lights touch. So if you have 2 direct lights and 2 bounced lights on a pile of objects, there will be a noticeable drop in perf.
I can't say that turning those bounce lights off will be less noticeable, in fact it might be the opposite in my case. I guess it all depends on how the author uses them. -
16 minutes ago, cabalistic said:
Less expensive, possibly, but again, it would depend how many pixels actually benefit from the less expensive model and what kind of effort you'd have to take to make the blend between the two not pop out too much. And exactly how much the difference between the lesser and the full model really is.
As for rendering fewer pixels in the distance, that's not really possible, because GPUs traditionally don't really work that way. Or rather, it would require a very new feature called variable rate shading that is only supported by RTX and RDNA 2 cards. And only RTX cards support it for OpenGL. Don't think it's worth to implement for those cards alone
Right on, thanks for the clarity. Yeah it looks like just reducing object count /light interactions the good ole fashion way will have the most impact. Ill see if I can put something together.
-
2 hours ago, cabalistic said:
All we are asking here is a demonstration that in a situation where a light is barely noticable (visually), it is still sufficiently impacting performance that implementing a distance-based culling system for lights would be worth the (potentially considerable) development effort.
Yeah this is tricky, frivolous shadow rays *used* to be a big issue, but with all the renderer and GPU updates maybe not? I wonder if transparents, alpha tests, and FXs are bigger culprits now. Having a light touching a glass window with fog and trees behind it might be a worse case scenario.
Would switching to a "less expensive" lighting model at a distance be beneficial or even feasible? Are there less accurate, but cheaper lighting methods outside of just shadow/ no shadow? What about texture resolutions? Would rendering less pixels at distance do anything for us? Sorry just kind of troubleshooting here.
@MirceaKitsune @duzenko I think the proper approach here would be to open up a heavy map like TPW or the opening shot in your FM Mircea, and look into the impact lights, emitters, transparents, ect are having on it. I'm sure turning off lights will have an impact, but doing it in an elegant manner might not feasible.
I'll look into this a bit more this weekend and see if I can really prove that dropping lights out can A: give back enough performance in enough situations to warrant the change and B: actually be done in such a way that isn't glaring to the player. -
2 hours ago, peter_spy said:
I get that this idea sounds great on paper. Technically, you could turn off all the shadowcasting lights and reduce your shadow tris to 0, and overall tris count by 1/4th, or 1/3rd even. But I'd hazard a guess that this is nearly impossible to do without the level looking awful. I'd be curious to see a practical example proving me wrong though.
Got it. Regardless we should be able to get light models to hide if not the lights themselves.
-
1
-
-
21 minutes ago, peter_spy said:
Hmm, I wonder what would that be, since e.g. both Unreal and Unity have LOD systems, and even some pretty fancy fade in/out editing tools (see: https://docs.unity3d.com/Manual/class-LODGroup.html), but none of them have anything like that specifically for lights.
Yeah its possible that lights are harder to do, but maybe more feasible in a dynamic-only light engine like doom 3.
-
Also we should probably discuss light clipping and lighting techniques in a different thread as that's own can of worms.
@duzenkoSo for the hide_distance stuff it looks like these things would be helpful to add to the list:- Func_rotating and other movers?
- SEED (more so investigate why they aren't working properly)
- Lights, specifically entities that spawn lights and FX.
If we can get a gentle fade out / in on all those things that would be incredible. Basically we'd have an industry standard system. I can see lots of cases where gradually dropping out lights and objects at distance will significantly help performance on larger maps or outdoor areas. Also being able to fade out FX when you get close to them is valuable for stuff like fog. This helps prevent "washing out" the screen when you get close to an emitter.
-
1
-
5 minutes ago, peter_spy said:
I think this could be done by using spot lights, not sure if that's what Duzenko meant. But that's a common gamedev trick too, using spotlights to avoid hitting too many surfaces by a shadowcasting light.
Yeah you might be able to use a spot light, but that wont work for most of our custom light entities which use volume lights.
There are definitely ways around this problem. My point it is they are fiddly and time consuming and in some cases require specific engine knowledge. It might be easier for a mapper to just hide that light at a distance or yeah draw some kind of clipping volume.
-
@peter_spy Yeah so I had to turn off a couple things to get it to work, new front end renderer and obviously use stencil lights. You might also have disable uncapped FPS.
@duzenkoNo unfortunately you cant clip light volumes in that way. You can move the volume to fit the space so it doesnt go outside the wall and then adjust the center. However, thats pretty time consuming and it wont work for lights that spawn and attach things to their entity origin, torch flames for intance. A lot of authors use the custom light objects that automatically def_attach lights and FX, so those rely on the center and origin being the same.
it would be pretty useful if we had a kind of brush that just acted as a light clip volume that stopped the shadow rays. It would give us more explicit control for sure.
-
Edit: Keep in mind in the top image, the light debugger is showing where the light is bleeding through so thats why you see the back wall illuminated.
-
Okay so Ive updated the test map to reflect this. Maybe this isn't an issue with shadow mapping, but I dont know. Dmap and then load it up
So this is the common scenario.
A light inside a closed portal is still bleeding through the walls and shadowing the boxes on the outside of the building. Obviously if I add a door we won't have this problem, but this isn't always feasible. In complex spaces this happens a lot.
Now if I could just hide that light at a certain distance I can eliminate that problem.
There might be other ways to fix this problem, but once again in complex spaces (which are most city missions) this happens more than you would think. Its not a systemic solution, but it could give mappers more control.
-
2
-
-
4 hours ago, duzenko said:
Awesome for speed?
Can we have a benchmark setup for this?
I don't argue that it would improve things, but I'm skeptical on how much it would improve
Awesome for mappers, as it will give us another avenue for controlling light count and performance.
Ill agree that its an edge case, but if we are supporting lights with models hiding or fading out a distance, street lamps for instance, wouldn't we need code to turn lights off anyhow?
Fan Mission: Volta II - Cauldron of the Gods by Kingsal (11/30/17) V2.3
in Fan Missions
Posted
@Acolytesix All of the statues should spawn optional useful items. If it doesn't spawn something then this is a new bug.
For the statues:
One unique hand per statue is required. You do not need to bring any more parts of the priest other than the hands.
I don't know which areas you are trying to get to, but you can access every place the apebeasts can. Try using vine or rope arrows or just explore. You should be able to get there.