Epifire

Shouldn't you be able to override it by adjusting the db levels from the sound shader file? That should fix it even if it's only a local file modification. Downside is that you'd have to do that every time you updated, unless it's a mission specific asset. In which case you could just tweak the soundshader and call it a day.

If it's model based I can open/edit any LWO based files but I hadn't been told we needed any fixes on them. I probably should check the bug tracker but I wasn't aware we were needed fixes. Although that being said I wouldn't mind tracking down all the red line asset based errors that occur on startup.

Really great additions for the final version, bravo! Looking forward to seeing what Act 2 holds next!

Goldwell voices most (if not all?) of his own protagonists for his FMs. Any time you hear that "TDM Garrett" in a FM, you know Goldwell has struck again! He got me started and gave a lot of tips on my own voice acting and now I'm doing an antagonist for my own FM work. Multi-talented fellow and really is the living definition of the jack of all trades when it comes to modding.

Yeah modeling the exterior will definitely be your best bet. Trying to do the outer hull with brushes/patches sounds like it would be a total nightmare. It's also a prime candidate for some vertex blends for darkening/wear as well as the waterline for the material. I could help you setup the UVs/Blend material for that if you wanted, as it would certainly help give it some visual oomph for texture detail.

Clean design and great dedication for detailing that layout you have. Do you plan on getting a modeled ship hull detailed out after blocking in all the bulkheads and rooms? There's a pretty quick and efficient way of going about sealing and portaling various sections if you don't mind shear invisible clips off the sides of the vessel. The clips would only be noticeable if you needed the player to swim close to the waterline.

Well I've tested this with the bucket visportaling I do and some stuff outside the bucket (that can't be seen directly) still gets rendered but only at maybe %50 of the shadow casters for some reason. So directly overhead of the bucket a single region would actually help but again it's a case by case basis. The method still needs to be weighed out with constant checking of performance stats and where different bits still render out of direct line of sight. I think the region light controlling will help to a degree but I don't think it has to be overthought either. It seems to have the best application where you want climbable rooftops and unhindered outdoor visibility. When the mission comes around to release, I'll be sure to document some of these performance steps if they end up in the mix. Apologies for semi-derailing the thread topic, I didn't mean to get so far off on a tangent.

Yeah man it's actually your lowres game mesh that's facing the problems. The UV islands should be one side of the problem (if you're baking the hard edge) but that has to be referenced in the final mesh as well otherwise you'll still get that weird shading going on. I'm still trying to remember what all 3DS needs for that to be saved into the exported version. If all else fails you can still achieve it by splitting those edges manually but that'll increase your vert count a tad. I mean it's a simple mesh so you'd be able to get away with that no problem but it's a last resort if your hard edges fail to export correctly.

Oh man I totally get that. Here's a great way I think I can explain how I'd go about combining things. Because yeah, some stuff really shouldn't get tossed together because too much of the same building will be rendering (at more times than it would have been) and possibly overlap into other visleafs. I think one really good method is to see what's being rendered in wireframe and seeing what continuously renders the most at any given time. That gives a clear basis as to what can then be combined with little to no hampering of frontend rendering as you describe it. Region lights are a stupid silly kinda trick I'm playing with. So the elevator pitch to describe region lights is to split the super large (moonlight for the whole map) into smaller regions. The goal then would be to run a script that checks the players region and toggle the appropriate light tied to his zone (while turning off the others). Zones would have to be approximated by PVS so that far areas aren't noticeably dark. But this would allow creation and smooth play of very big maps while keeping that pesky dynamic moonshadow count in check. That being said a script would keep things in DR cleaner, and would allow regions to operate independently. Say if you nocliped and started tripping zones out of sequence, the script could just check states (like the elevator script checks platform stops) and would prevent the moonlight from breaking. This would also eliminate the usage of on/off triggers or the expensive, "always checking" trigger volume.

The material choice really pops. Only thing I might add is you may wanna set those inside edges to hard, as it looks like the soft edge is putting off some small but blotchy inner shading. Other than that I think it's pretty mint!

Obsttorte normally I'd agree but I'm combining things on a per-visleaf/view basis. Meaning the things combined were already going to be rendered regardless of where the player was standing in reference to said building. Some things still remain broken up a tad, or at least enough to not completely undermine the PVS culling. I've got some fairly complex module material stages that have redundant duplicates abounding for just one building, so it's a needed step. That said I've been able to shed close to 1,500 drawcalls and manually cut out another 5k shadows just from combing three bigger structures. I'd also been working off of a, "visleaf bucket" standard where interior details of a keep, garden or compound are being created like a bucket with a visportal cap on top. This means that any time the player is outside (or more importantly below) the walls, it'll separate other expensive detail bits of the adjacent leaf all while remaining entirely open to climb over. I've also been considering methods for controlling region lights in a similar manner. Only thing is, OnTouching trigger values seem to be rather expensive for id4, so it's a bit more manual to setup the trigger gates. Noshadow or texture lights are an absolute must in this build strategy but it currently performs really good for having so many things in constant view.

Fantastic work Greebo and thanks for pointing this out Biker! I really only map with models these days and I was having to eyeball module placement (in my modeling app vs DR coordinates) to turn a 30+ mesh building into a single model. LWO is my naitive file format for working on TDM, so this is gonna save me so much time! Rare is the case of an old gen level editor, where optimization is ever fun and easy.

Yeah man I'd say this could even go for a alternate skin for the frame if you were feeling it. I'd say both wood and stone would look good. Some stone block cuts running from both sides of the frame would look slick. Kinda gives me Dishonred 1 vibes with the propaganda signs for the City Watch.

The example Arcturus supplied uses an almost identical mtr that Nbohr had listed minus the RGB line. My assumption is that mirrorRenderMap requires additional data by default because it'll fail to project correctly if the function is just used by itself. The only difference I'm seeing compared with the parameters others have used (without the vfp) is it will apply the fresnel like a mask to refine the areas it reflects. Reflections in the prior image I posted are running but not at high intensity. This is the same material set with greater power... Note the surface is completely opaque as I haven't made any water depth adjustments. I'm going to have to substitute the texgen reflect (cubemap) of the water's surface to HeatHaze I recon, as I don't think cubemaps will accept scroll values for wave motion. One other drawback is that the cubemap's own generic reflection stage wont update with a moving _local map in my own tests. I know the cubemap itself is a static image but I was hoping I could scroll the local stage it refers to in order to get the motion needed. I really don't want to use specular maps as it's probably the worst generic map to use for water. However I may not have much of a choice there either. For most reflections, this would be a piece of cake if we had access to parallax corrected cubemaps. Also something crazy to note, is that the mirror doesn't like props without a bottom. I've noted on the big footings I used in the shot (that don't have a bottom) get skewed reflections streaming out behind them. Relative to the player's view of course but it's a minor bug to note. I guess my decision now is to figure if it's really worth the performance deficit to use the mirrorRenderMap stage at all. It's for a very large and very open map that currently runs great but I can guarantee it'll bog lower end systems with this puppy doubling the render budget.

I'd certainly be down to test one out!. Wednesday and Thursday of this week are my best days to reach but I can probably test when I'm off work as well.

Interestingly if I remove the vfp line from the mtr the reflection will break. This is what spurred the idea on because I'd noted that the mirrorRenderMap has always done this same graphical glitch in the past (shown below) but was due to me not pairing a vfp in the material definition... That's when I started asking myself exactly how bound the mirrorRenderMap is to the vfp hooked into it? Thing is I don't know jack about ARB but these are just my ramblings from many frustrated hours of tinkering with it.

Well from what I'm gathering the dynamic reflection is re-rendering the scene. I guess what I'm unsure about is how much of this re-rendering is shader dependent, or what other arbitrary functions are being calculated as mandatory steps in run time. I was under the impression the vfp is containing the math/commands to define what's being drawn up for the reflection. Under that same assumption I was looking to create a stripped down vfp that skips certain aspects of the rendering. All I really need is the basic shapes of buildings and shore to complete the water line. It'll be blurred beneath other layers so it's not required to be %100 accurate with shadow casting. If it can reference texture data and ambient world lighting that's plenty helpful for it's purpose. Of course this is assuming shadow rendering can just be skipped at this stage. Otherwise I'm kinda outta ideas for tonight. On a separate note is this fresnel.vfp, and that is the fact it cannot render the skybox (otherwise being a projection of a projection). Is there a way to just insert a black mask to substitute the space of, "nothingness" it's attempting to render? Then you'd have a mostly condensed image where a skybox cubemap can just be thrown on top of that to complete the sky reflection. It would be even cooler if the cubemap and mirrorRenderMap could be combined in the same MTR, but I get a, "too many texgens" error if they're based in the same material. Long night here messing with this stuff, so I hope most of that made sense.

So yeah as by the title you can gather I'm attempting to gather good shader and MTR info on completing good water. What's paining me most is that I can't get even relatively close to good reflections and it's bugging the hell outta me. I've got a pretty snazzy material that can provide worthy generic reflection (from say a cubemap of the skybox) but that can't constitute the water line of shore, docks and buildings. This brings me to the planar reflections of a stock material I found called "textures/water_source/cave_water_reflective_01" { qer_editorimage textures/glass/glass1 translucent noshadows nonsolid { blend blend mirrorRenderMap 1024 1024 program fresnel.vfp vertexParm 0 0.6 fragmentMap 0 _scratch } }This simply doesn't work if you're using a normal skybox, as the mirrorRenderMap stage doesn't recognize the skybox projection and reflects a backdrop relative to seeing a leak. However what it will do is achieve the water line reflections I seek. At the mercy of recasting and rendering every single shadow in the map (yikes!). Now I'm not accustomed to the workings of the vfp but is it possible to condense/create a simpler one that doesn't relist shadows twice? I only need the silhouette that the planar reflection can provide as it wont be used wholesale as the primary effect. My goal is to layer this reflective pass (to gather waterline reflection data) and then fill in the blanks of a skybox backdrop manually by layering in a cubemap blend. Then what you'd have is proper world reflections, decent sky and cut the additional shadow cost. In the end it would be some fancy water, without the fancy overhead budget. I'm no expert to these materials so if anybody has a simpler method to getting that water line, I'm all ears.

@ERH I'm actually really curious how you got the water reflective pass to work? Looks like it's drawing directly from the surface? Any time I've tried to use the pre-existing real time reflective capture, it broke my skybox and skewed the resulting reflection. Would be pretty shook if you revealed how you got that to work.

I think it requires a def file with constraint data? I'm not sure how else we'd go about that so lemme do ya a look here. Aight, so digging into some of our def files I think I can point to the block that will properly handle your ragdoll. These are used in TDM but considering these look pretty standard, I'd say they're inherited functions from the original D3 ragdoll system. One thing to take into account, is if you're indeed using a brand new monster (and importantly with new rig with anims) you'll most certainly need to define this somewhere for the game to understand your rig's ragdoll constraints. I wanted to create a roller bot at some point but I haven't delved enough into this process myself to be %100 certain but hopefully this will help. *Taken from tdm_ai_base.def* If it's any help, you may want to compare this to whatever default base you're pulling from in stock D3 assets. "Editor_var_ragdoll" looks to be of the greatest interest to what you're encountering, because I'd imagine if the game cannot locate a proper .af file; it's likely to be kicking it to Tpose for lack of identifying the correct information. If you do have all this information lined up in a working def file, I'd second check the lines for typos as well as the integrity of the af file itself. EDIT: Did a tad bit more searching and I think this .af file crops up in one other spot (directly on a character def file). It's worth assuming the articulatedFigure declaration is searching the .af file so maybe this is closer to what you're needing. I'm starting to get kinda curious how to rig up some of this stuff myself now that I've been rummaging around in these folders a good bit. Either way hope that helps man!

So I can't seem to locate what's been added feature wise (or when) for an exact list so I thought I'd just ask. I heard we'd be seeing support for a common video format to be added into TDM with one of the updates. I'm assuming this video could be ran in a shader format to display on a screen of sorts? There'd be a lot of fantastic uses for that and would be much easier than the severely outdated ROQ method. Also it's worth asking if embedded video audio be played directly in sequence?

Honestly I really need to just sit and go through the Springheel vids myself. Most of my time tends to be chalked up to custom environment assets but there's still a great deal of simple gameplay design in DR that I know little about. The idea of covering all the essentials in a direct video course was a great notion and one I'm still very thankful for having the quick access to.

Sad to hear this, I hadn't known him personally but it's a hard thing to lose one of our own. I hadn't played any of his missions yet but just listening to his sound cloud alone, there's so much depth and emotion. A shame indeed, he will be missed.