Search the Community

I am currently looking into vertex blending because I want to try to help GC out a little. The blending and all that is no problem, but I do have problems with applying different surface types to the two blend textures. Here is my material definition: textures/vblendtest { surftype15 description "dirt" qer_editorimage textures/darkmod/nature/grass/short_patchy_grass01_ed noSelfShadow // Blend texture one: grass { blend bumpmap map textures/darkmod/nature/grass/short_patchy_grass01_local VertexColor } { blend diffusemap map textures/darkmod/nature/grass/short_patchy_grass01 VertexColor } // Blend texture two: dirt { blend bumpmap map addnormals( textures/hell/dirt02_local, heightmap( textures/hell/dirt02_h, 8 ) ) inverseVertexColor } { blend diffusemap map textures/hell/dirt02 inverseVertexColor } } Of course, I would like the grass texture to actually sound like grass. Anyone know how to do that? I already tried putting separate surftype15 statements into new stages together with the according VertexColor statement, but Doom 3 didn't recognize it.

So... What was up with the forums all day yesterday..?

Hi. In my map I've used the texture numberwheel_wood, located in Other Materials in the Media browser. It seems to work just fine, like any other texture, in-game too. But I've noticed that it does not show up in the Texture Browser like the other textures I have used. I've tryed with other textures from the Other Materials folder and they dont show in the Texture Browser either. Should I be concerned about that? I'm using Thief's Den ressources btw. Jesps

[update] Spoke to Marcus @AMD UK on the phone and as it turns out a number of complaints have been made against "Spyre". My AMD forum account has been unbarred and my Ip address unblocked!!! Bought a new gfx card for xmas, been having issues with mainly the driver So I though a good place to look for support and polity vent etc - or so I thought My second post got flamed by some smart arse fanboy and then promptly locked, to which I reported the posted asking why it had been locked.. and then my account on there got deleted and my Ip blocked (untill the isp dhcp refreshed etc) so I cant login even with a different account name. I have emailed AMD directly about this as I did nothing wrong according the t&c's and I got no warning Pm or email from the forum mods. Now I've been over at the nVidia forums a long while back when I had the 8800GTX when I was equally frustrated when posting about the driver issue with thief etc, but at no point did a thread get locked or worse my account deleted. I don't have loyalty to AMD or nVidia but depending on the answer I get from AMD next week this card maybe going back and AMD will be added to the list of manufactures I will never buy anything from again. So whats the moral of this story, well take your pick.. [update] found cached copies of 1 of my posts Cached AMD frum link Cached AMD forum link2

when i do a search, it give me some results, I click on a result and exspect to get taken to the post it specifies - but no..... I get taken to the first post of the bloody thread it is in..ggrrr

This issue: http://bugs.angua.at/view.php?id=1573 has opened up a question. The bed sounds like wood all over because it has a CM built into the model, and the CM is wood. I don't think a model can have more than one CM (movables can't), so that leaves three options: 1. Remove the cm 2. Leave it as is (wood sounds all over) 3. Change the cm material to cloth (frame won't act like wood). Opinions?

Edit: Since this thread is bound to be misread, misinterpreted and dismissed immediately as something it is not - a reorg - I'm editing to add one statement at the top: It's not a reorg. </edit> ------------- In looking through object and material names for sorting order fixups, it becomes clear that we of course have some inconsistency among the way things are named. This is understandable; after all, who knows if something should be called "large" first, or "blue" first, or "dirty" first? There are unfortunately worse examples, but that demonstrates the point. Because of this, I think it's probably a good idea for us to establish convention. Here is a suggestion, just to get it out there and started, which if we agree on, could be considered for all new things coming in. Existing stuff is a separate matter, and can be handled (or not) separately. Some or all of the following apply to any given model or material: 1. Object Type descriptor first (mostly for models, or very specific textures) - it's a lamp, a door, a chest... 2. Material descriptor next - made from marble, wood, mud... 3. Size descriptor next - it is large, small... 4. Quality descriptors next - texture-wise, it is rough, new, cracked... 5. Color descriptors next - what color is it? red, green... 6. Number increment last - which of the list is it? 001, 002... There's of course some play in that; if someone defines a new size ('huge') for instance, it'll stand alone at first. But as long as the person establishing precedent does so within reasonable guidelines, they'll set a good example for everyone else to follow. Material example (fictional): slate_large_cracked_grey_001 Omits an object descriptor - it is a general, non-specialized texture. Why is this preferred? Some existing materials are named by quality descriptor first (e.g., 'cracked_slate...'). This throws the user off, because they were looking for a 'slate', not a 'cracked'. Model example (fictional): door_wood_battered_005 Omits a size descriptor and a color descriptor. Why is this preferred? Some existing models are named by quality descriptor first (e.g., 'battered_wood...'). This throws the user off, because they were looking for a 'door', not a 'battered'. Your thoughts? If you have a better suggestion, please suggest it. It would be good if we can establish something official. We could put it up on the wiki as part of the guidelines, and all future objects and materials will be named in a user friendly manner from the start. If we do not do this, naming will continue to be 'humanly inconsistent' to no individual's true fault, but to the detriment of all users. Argument in 3...2...

why are they so slow this evening..??

I'm seeing new Collision Models being made that use the D3 textures/common/collision. Unless there is some reason to use that which I'm unaware of, we should be using the TDM ones in collision.mtr, corresponding to material type (tdm_collision_wood, tdm_collision_straw, etc).

The forums have been upgraded, please see this thread: http://forums.thedarkmod.com/topic/9845-forums-upgraded-to-ipb-3-0-3

I was just playing around with material files and have thought of an excellent way of doing wet textures for every material that could have it. This would be set by the mapper in the map and would mean that instead of having 2 materials - one for dray and one for wet, we could just have the one material and be able to set a shaderparm to make it wet. The other advantage of using a shaderparm for this is that you can through a map script make a room etc look gradually more dry or more wet, not to mention other effects, such as making a dry basin appear wet when it starts getting filled with water etc. You can also make it (through script) gradually get more and more wet, simply by incrementing the shaderparm. I have used the in-engine texture (_white) for the wetness texture. This means it is applicable to all textures we currently have, and all it requires is to add it to the material file. I can do that if noone else wants to. Here is a screenie of it in D3: Here is the code in the material file: { if ( parm5 > 0 ) blend specularmap map _white rgb 0.25 * parm5 } By setting shaderparm5 you can control the wetness. Of course, it defaults to 0 (not wet), and by 1 it appears wet. In the image above the settings are (from left to right): 0 (dry), 0.25, 0.5, 1 (wet), and 2 (too much) Anyways, I'll tweak it further and see what I can get. Of course, if this is implemented, it will not break anything, but textures with already existing speculars will need tweaking to work properly. The other only limitation is that this wetness property cannot be applied to worldspawn, so any surfaces using it would have to be part of an entity, such as func_static. Hehehe, just imagine a wet AI or even better, the player weapons when you crawl out of a river and are drying off

While parsing the def files, I found this: e.g. there are material and skin definitions inside a def file. These really belong to the material/ and skin/ folders. But maybe there is a technical reason why they are inside def/? If there isn't, I am gonna move them to the proper folders.

Just returned from a 7 day holiday, opened up this forum, had at least 4 pages of "new content". Made it past page 2 (to about June 03), and then had to take care of a few things here. When I came back, the forum had logged me out (timeout?), and when you log out, it forgets all "new content". So you log in, and it says "there is nothing new for you". Great, now I never know what I missed between May 30th and June 03.... grrrrrrrrr With email, you would still have all unread messages *sigh* Is there a way to change this behaviour? It has annoyed me in the past, but not as much as this time.. Edit: It's even worse, there is "no new content", but when I go f.i. into the "off topic" sub-forum, it still shows me threads as unread that I definitely already did read an hour ago. So I can't even just look at all the "unread" threads. Oh boy...

I was considering posting this in programming (as it also touches on the frob system and it is a declaration afterall) but it seemed more appropriate among texture materials. Why does this (part of our frobbing system) work: diffusemap sometexture { if ( parm11 > 0 ) blend add map sometexture rgb 0.15 * parm11 } And this (adding a particle to a surface) works: diffusemap sometexture deform particle2 someparticle But this (using the same conditional logic from the frob to add the particle) does not: diffusemap sometexture { if ( parm11 > 0 ) deform particle2 someparticle } And it's not just that the particle doesn't emit - the whole texture turns black/broken. Note that I also tried using blend keywords lifted 1:1 from the frob and particle emission techniques, to no avail either. I do have some minor programming ability, so this is not completely foreign to me, but I cannot see what the problem is here (unless it's just a limitation).

Announcement: http://forums.thedarkmod.com/index.php?showtopic=8900 Please post any comments, bug notices, etc in this thread. If you have any issues with the new forums, please try to refresh/remove your Internet browser cache. Thanks ~m2

Ok, this evening I spent time fixing all the materials (other then what gild did obviously) to use the hybrid frob code. It's all done and up on cvs, but please for the love of god, any future materials made PLEASE write the hybrid frob code for yourself, because it's just a pain doing it for hundreds of them. Well anyways, it's done and on cvs

I'm implementing frob fade in / out, and noticed that a lot of the materials on CVS that are frobable still have the "if Parm11 > 0.5" code in them. I thought we had replaced those with just brightening up by Parm11 to support frob fading?

I've just completed the upgrade from IPB 2.2.x to 2.3.6, the newest official release of IPB. This was done to stay ahead on the IPB version 3 that is currently in the beta stages. Please post any comments, bug notices, etc in this thread. PS: If you have any issues with the new forums, please try to refresh/remove your Internet browser cache. Thanks, ~m2