Epifire

If I'm reading this correctly I think it's just some needless complication I left in the material. As a matter of fact I'm not even sure why it has a local map when it's so tiny to really not need it. I was pretty extra back then but I'm 99% certain this is something off in the MTR. I'll make a note to self and check this when I wake up tomorrow.

feather_duster_001.zip Okay, it's super lightweight as I didn't wanna kill the budget for a tiny carry-able but I think it'll do the trick. Give me a holler if something is up and I'll try to take a look at it!

Alright, so here's the first pass. If you want it more dense with feathers I can add in more. The lighting is a bit harsh but I'm kinda running into the limitations of our lack in subsurface scattering. Or soft alpha filtering. Let me know what you think, it's super simple but I figured was about the detail you'd need. NOTE: it's only static so it'll need a collision hull treatment if you want it to be player-chuckable...

Sorry I'm not near as active on the forums these days since pursuing the portfolio again but this could be quickly whipped up I think. If anything I'd just need to get a suitable material for the feathery parts to look... feathery. If Springheel provides a model, obviously we shouldn't need two but in the case that cannot be done I'm sure I could come up with something.

While it seems like the next step at pushing boundaries, (which is what HL games tend to try and do) they intentionally didn't do this with HL3. I see this as a creative reintroduction to the series and my hopes are that we finally get some kind of EP2 sequel in the not so far future. As a major HL2 fan (that being the game that kept me in modding btw) still has me really stoked. That will however leave me very stoked and broke for the next couple months. ?

Thanks! It happened to be the only map I had to test with water and a working cubemap already setup. However one day when I'm ready to get back to work on it, I'm hoping to reshape it into a neat FM.

A new Gondola for Neon's project. (NOTE the background map isn't related to it). Still kinda swamped with stuff to do (and other requests!) but least to say the Epi is still cranking models here and there.

Ahhh my bad, I thought the camera tutorial was just for the one that buzzes the alarm if it spots something. Yeah that looks to be the reference material I was needing. Just kinda wanting to reverse engineer some template so I think this will work.

Yeah it's not working now on my end either. Trying to figure out why the hell we keep having so many outages in recent.

Currently mission downloader is dead again. Where are we at with this? We've had several months and we're still running on a stand in forum, no bug tracker and I still haven't heard any news on what's being done to remedy this? I understand things take time but we're starting to lose more functionality rather than see things fixed. And it feels like we've had overall less traffic on the site because of it.

Hey quick question, how do you get a camera position to be rendered in real time to a material surface? Wanting to create a neat effect but I'm having a hard time tracking down documentation on the matter.

Yeah I think I messaged around asking anybody at one point if I could look at the current resources for it. A lot more busy just trying to wrap up current requests and getting back to the portfolio but I'd still like to help out on that again if I ever get the chance. Had talked to Kingsal at one point about what adding my own NPC's would take. So while I'm busy af right now, I'm still really keen on working with animations (especially since I'm now learning Maya). ? I just wish id4 had more broad plugin support with other, more modern modeling apps.

It will probably have to change for me in the future but I hate drawing myself my own concept. It's a strange thing but I feel a lot more comfortable (usually) just hammering it out in the editor rather than going through a ton of concept. I do the thing where I take down notes that I toss on my desktop and usually refer to online references of the real thing I'm trying to attain the look of. But that's also from a modeler's standpoint where I do a lot of blocking and going over the design in the early stages of it anyways. However. Having very rarely been given 1:1 concept art, I will say knowing the shape and color pallet to something before even starting it blows my mind. I think drawing your own concept really depends on your workflow because I used to do it in the past but dropped it because it somehow gave me tunnel vision on the scope of the project right off the bat.

I brought it up originally just to hear our coder's thoughts on the concept. As mentioned in the status, I'm a big advocate for implementing (or improving) tech already very well associated to other idtech branches rather than trying to overhaul it's core architecture. We can improve things within a certain degree but at present, even if you had new tech to run TDM on; you'd have to patch the majority of our assets just to render it correctly. What I really would like to see added to TDM follows as... -Parallax corrected cubemaps with batch node building and macro-asset assignment (possibly my most asked/requested feature). -Optional lightmap system for BSP brushwork. -Vertex paint mode for displacements/patches in DR. I rant all the time in the TDM chat about cubemaps because it's such a powerful yet underused feature in TDM. A: it's barely accessible and B: it's current projection method limits it's practical usage. Current cubemaps do not shift via the player's spacial coordinates and they're really a damned pain to create for them to be feasible. Source Engine cubemaps weren't a great deal better in the projection side of things but the build method was 50x better than what we've got. Bare in mind it still uses player position to take the six sided snapshots but it treats the cubemap nodes (placed by the mapper) as player coordinate data to batch build all cubemaps from a single console command. Would stringing together entity positions in a batch automation be that difficult to create in our instance? Lastly I bring up the cubemap assignment/usage. Probably the most painful part of our current system is it requires you to painstakingly create a new material definition for each time you want a new cubemap for a new asset position. My proposition before was to have a generic default block running a kind of if statement. Exactly as our param syntax can look for code additions, my idea was to have this generic block (in a cubemap optional material) look for a cubemap keyname. That if referenced in the model via spawnarg, the material would modify the expected path and fill in the cubemap keyname. This would mean you could have 10+ cubemaps all being based off the same parent material. No more custom MTRs for each! All the mapper would have to do then is drop in a cubemap node, match that node's keyname to a spawnarg on said model needing reflections; then build cubemaps via console command. A fair bit of additional framework I can imagine but that is the ideal situation I could see us benefiting from as a whole. Just improving what we already have, without needing Nvidia specific hardware.

Just got the alternate, "smart" paths worked out; bug free! Thanks again all, I'm sure I'll be back this way when I get some more gameplay nonsense to work out!