Serpentine

I've been sitting on Freenode in #thedarkmod for a few months, you're welcome to join.

I have applied a temp fix for this. The lights will show as normally lit, so there might still be a small flash, but for 1.08 testing so long, it should be way less distracting. I'll look closer into the entity stuff when I get some time - I want to get the screenshot fix done ASAP, sort of forgot to finish the patch once I started looking at this/lg.

Not sure about the hard edge on the ring torso - but the rest is looking really nice

Nope, this is what it solves in part, if you need pathways or randomly blended (like, blotches of textures), you will be able to use it by just applying the material to a patch and dragging things around. The idea is to give an alternative to the traditional models. The trick is finding what type of blends would be most useful, and then how to work out how to code the right logic for selections - i.e we need paths, how do we paint the outside vertices one color using some logic - this then just gets made into a keyword in a material and the mapper needs to know nothing of the magic behind the scenes. Doing it directly in the map, with vertex painting is near-impossible and would require some insane refactoring of so many components and low level assumptions that at the end of the day, its simply not worth starting on imho. As for making the materials, they are actually fairly simple when you look at one. At the moment this is just an idea - as I said, the implementation that I did was very crude and it could not be completely feasible. But I plan to throw some time at it in the next week or two.

It's about 60mil short of that~~ But yeah, it would be a really nice gesture if they took in some of Sik's work; I doubt he'd have any problem with it (and a cheque in the post wouldn't hurt) for much and it'd be really good PR; then again I'm sure the Marketing Guys, after studying the situation have found that people don't actually want any more features in a re-release.

“Marketing folks are pretty smart. They’ve got MBAs, they spend their time studying games.” - Tim "The Profound Salesman" Willits For more amusement : How Tim Willits Sold Rage's vehicles Games are no longer about gameplay, they are about marketing.

If you could just zip the bobsfm folder up and upload it somewhere, I will edit the material/model to work, and from there you will get the idea of how it fits together - it's pretty close atm

We'll have moved to our own engine before this matters - I also have a lot of doubt as to what they will be updating/changing; it all seems to be pretty minor content changes, the HMD stuff is mostly already in the engine as far as I can tell (It supports stereoscopic glasses last I looked).

I'm pretty sure most of those are already in... ?

Or multiply/divide by the keyword 'sound'. void idMaterial::EvaluateRegisters( float *registers, const float shaderParms[MAX_ENTITY_SHADER_PARMS], const viewDef_t *view, idSoundEmitter *soundEmitter ) const { ... case OP_TYPE_SOUND: if ( soundEmitter ) { registers[op->c] = soundEmitter->CurrentAmplitude(); } else { registers[op->c] = 0.0f; } ... On maps with combo light entities, like the electric lights or candles, the soundEmitter is never != NULL. Yes and no, considering the problem can easily go unnoticed - I think the warning has a valid reason.

The light entity does not know which soundshader it should be using for sound's value, as such it falls back to 0.0; which will give it that pure white. The default could be changed to 1.0 which would give you the 'normal' brightness, but it'd still flash in this case. Pretty much, the combo entity needs to tell the light what sound it should be using, at the moment it doesn't seem to be - or at least not as it is created.

Yup - the problem lies on the TDM side of things, the amplitude is being worked out correctly, except that there is no referenceSound for the lights (tested with a manually made one). I take it that this is a result of the recent light entity changes. There seems to be some generic refLight, which might have been getting used. If someone else wants to look into that, otherwise I'll check it out in a few days - I don't really know what happens on that side of things.

Ok, taking a closer look at the white light issue now that the portals are sorted. Using a render from just after the gpl merge (i.e before me), the problem with the flash is actually still there. The only difference is that it's not white, its black and as such doesnt show up. While that may sound better, it only hides the real problem (that problem leads to anything from rooms with no working lights to entire maps or out-right crashes in the case of some of the d3 materials). Its likely that its been broken since the gpl merger, or on one of the lower level changes elsewhere. I have a few other suspects to look at now.

Hey there! Yes, but they arnt very hard to make for simple textures. Take a look at a few similar materials in DR (right click on the material -> show shader definition) If you need help with this, just shout and I can sort something out When you are working on an fm, you will make a new folder for your map/textures/materials etc. At the moment, this should be located in your doom3 folder. Your fm needs a short name, like 'bobsfm' - ideally something from the name of the fm itself. You will then make a new folder like c:\games\doom3\bobsfm\ ; in which you would create your own textures/models etc folders. As such, you dont need to potentially break any tdm stuff. To get the assets to load in DR, you go to File -> Select Game -> Mod = 'bobsfm' & Mod Base = 'darkmod'. You can think of this folder as being overlayed on the darkmod folder, so try to keep things in a similar pattern and you'll make your life easy, and should you wish to donate assets to the mod or over-ride assets, it is a lot easier. Textures are handled like this: Normalmaps - tga (this will change in the future, TGA is safe tho) Diffuse/Specular - dds (DXT1) However while you are getting everything working and want to make edits, I would suggest just using TGA for everything. Before release, swap out the tgas for dds. The material files do not need a file extension, making this very easy. Have you tried my exporter? See : http://forums.thedar...xporter-beta-1/ - it will let you skip the blender stage if you want, it can also export from .blends if needed. It may even support the cad format (it supports one iirc). The export is very basic, no vertex colour/normals at the moment; but that's not too much of a problem.

The images are hosted by me, and dont require any js or anything for the forum to give you the correct url - so I'm not too sure what would stop that from working. That said, I really wish IPB would give me the options to just edit/post in plain text with bbcode markup. This mixed html/bbcode/plaintext is so annoying :/

<p>1. Geometry already can already have its vertex colours changed - that's what the rgb/red etc keywords do. This is not all that handy as it can only do a single colour, tho maybe you could do some funny stuff with vertexColor stages. At the moment vertex colors usually end up correctly, however its possible for some unexpected colours to creep in (ASE models can specify both a base colour and then over-ride vertex colours, or just default). 2. CPU, rendered on GPU. 3. One material per surface, there's a lot of stuff that requires this to be true. It's not really a limit to much tho, vertex colours will give you the graphics, just use no-clip or whatever to map the sound. I made a little proof-of-concept (ages ago, and it's pretty useless/broken; I plan to re-implement when I'm more familiar with things) vertex colour transform, to allow patches and simple geometry to be given vertex colours to represent specific uses. I.e a material could specify 'deform path' or something, which would change the edge vertex' colours to black, and then using vertexColor stages later in the material, blend your path textures. This could then be fairly easily implemented in DR, avoiding the need to actually offer vertex painting - since that is not stored in the map format anyway. i.e a patch would have a path material applied, which would then be transformed like : Which would then be textured with the blending: It's low on the to-do list; Far bigger fish to fry first.

Hey, Only got my line fixed this evening. Before it died I was busy bisecting the versions, which you seem to have done. Thanks! I'll take a look into it on Friday evening when I have some time. Also, the bug might not actually be a bug, we may very well have been using an undefined behaviour, looking at the material files there is a good chance that they were dividing by 0/null; which is possible with shaders and can return some very strange stuff. It's why I use the bitwise operators in the water shaders to check if a value is value before trying to use it. Quite possible that I borked getting the sound amplitude or whatever the var is in the case (I was looking at the _snd shaders). You will also notice the way that DR reacts to these materials - _snd in specific is to show the pure-white (well, pure-ish, there's some colour that gets blended in on the fringe).

I think it just defaults to black at the moment - however it's not hard to change that, since anything missing should be mapped to 'default', adding a diffuse and additive stage like the 'shader not found' in DR would do the same thing as the HL2 purple tiles. Might be a good idea for the transition period. Maybe have a CVar to change the default material to something else (the default material is only 'found' once, so it's easy to do). Tels - it just makes it easy to spot missing textures, so that they don't just blend in and go unnoticed — good for testing, not for production. (I've no idea why they left it in HL2, since quite often their shaders bug out and you end up seeing the pattern :/)

Was the side black, or were there sparkles on the edges? Sounds interesting, might be vertex slopping then.

You can also get sparklies in areas where triangles are extremely dense, this can usually be fixed by breaking up the surface using a hard edge or dividing the large surface and nudging the texture slightly on one half. I've seen a few cases where there are slight gaps in walls where intersections have been optimized incorrectly as well, tho these are quite rare. Often what you're actually seeing is an artifact of the interaction shader when the surface area becomes unrealistically small, broken models give a good glimpse into that - I think the current music stand has a section where you can see it quite clearly... but that might have been fixed. Snap to grid, use func_static where needed to avoid excessive extra tris and you should be fine... but finding good reproducible cases would be handy if someone wanted to look at dmap later on.

Also a note : the 'sound' keyword on lights seems to be completely broken - I'm not sure if it's worked since the gpl release however. I'll try to check out a really old copy of TDM later for experimenting. It also seems to be related to some strange rendering - as the lights are in a strange state where the engine makes bad culling choices about them. In short, kinda broken at the moment. That said, the 'broken' lighting is really fun to play with, might be worth making a similar keyword for helping to place things like directional lights. If you're getting a pure white flash, it might be something dividing by zero or a null.

I just copy/paste, reindent as C code then make sure the material has the correct keywords, add a real description etc. Also doesnt hurt to double check editor images and stuff like that :)But yeah, all in all it's completely pointless trying to pretend there's some reason to retype such basic things... but you might as well add some value while in the area!

Yeah I've played with it quite a bit. It's also got some nifty stuff that I've been porting over to TDM. That said, dhewm3 will run slower than the gpl release for a number of reasons, so other than letting you use a bunch more memory and avoid needing 32bit support in your OS... it's not going to blow you away. Mostly the port is about portability

The lights arn't very hard to do (most of them anyway). I'll do them this weekend.

Errr, that's kinda strange :/ If it happens again, can you search for your 'doomkey' and/or 'xpkey' file, they should be in doom3/base. If they are missing, that's a bit worrying. CD Key checks have been removed in the upcoming 1.08 release. But... still an issue that could be problematic if it's somehow damaging files.