Epifire

Got another one for you fellas! So I was wondering real quicky, what resources do we have describing custom loading UI and menu header options? Specifically right now I'm tackling the custom FM loading screen (and loading icon). If MTR functions can be loaded in just like in-game this should be a cinch. I just wanted to have the title banner on a non-moving material with a circular element rotating infinitely around it. It's pretty simple in concept so I was wondering if someone might be able to steer me in the right direction?

"When science, faith and allies have failed us; whom have we sought but now a Thief?" More to show (hopefully soon!).

I'd dig option #2 and the whole TDS style Holy Water.

Such a great shot with the large gear forms being a major part of the scene and layout. Reminds me of how some very large imagery was crafted into the levels and layout of Bioshock Infinite. If you fellas need an extra hand with enviro detailing, I'd love to hop on that with you guys. I try and commit larger scenes to texture atlas and can be pretty flexible for mesh optimizations (shadow/draws included). It looks like some real fun for the portfolio, so toss me a PM if you're interested Dram!

If you make a junction brush out of that corner (connecting that inner vertex on the left to the three outer verts) you should be able to remove any shear angles for how far those triangles are stretching.

Well tbh, I think the light bulb was a much better choice. The plastic bits were squishing water out in a ring (deflecting away) when compressing at point of contact.

I've really wanted to animate stuff for a while, I just didn't wanna bite the bullet and learn Blender. However, I think I could settle for importing a finished model and animating it from there. Thanks for linking the tool Arcturus!

Hard to say as I haven't actually made the scary venture into MD5s, but does the game expect an explicit hierarchy for the bone setup? It would explain the strange deforming but that would be my first guess. Thing that gets me is every engine I've dabbled with animations for, have their own proprietary implementation. The result being quirks that need tending to else strange errors persist. Needless to say I'm very interested in seeing what could resolve in your case here.

Unless it's a tile specific resource you usually don't wanna use them whole sale from the repository (or at least just me). It's a bit more freeing to be on a procedural workflow now but it's still pretty valuable to find grunge layers and brushes to composite things with. Grunge patterns are easy enough to edit and tile in the edges if needed but man it's still pretty hit and miss to find good brush resources with all the appropriate height map data included.

Indeed great find! Really some eye candy seeing their brushes section too, as good brush presets save sooooo much time when working on a detailed project.

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.