Newbie DarkRadiant Questions

[peter_spy 1522]

Skybox is just a view rendered from a static camera, it's meant to be a fake background. You use it for distant landscape that would barely move or not move at all in relation to your movement. All other things should in the map area, as a distant art assets.

[STRUNK 270]

@Dragofer

How to get my dds file to show up in darkradiant?

Putting it in a folder named textures doesn't seem to work, and putting it in dds/textures neither ...

I think I'm missing some basic understanding : )

[peter_spy 1522]

Textures need to be part of a material, and dds textures in particular need to have mipmaps generated.

[grayman 2967]

Texture Creation, per the Wiki.

[STRUNK 270]

I tried putting it in the normal folder structure, making folders named as described .. I think, for this is not totally clear to me:

You will save the dds to : /doom3/mymission/dds/textures/brick/mybrick.dds

for a custom texture (only for FM use) you should use "../textures/darkmod/your_texture_folder"

But now I read: Most textures are in a virtual "shader subfolder"  ... Are these folders in some file and do I need some program?

I had no problem putting models I created in the right directory so I'm kind of wondering now ... do textures have to be in a totally different place?

I'm trying with just a blue square of 512x512 exported with gimp to .dds where I selected Compression: BC1 / DXT1 and Mipmaps: Generate mipmaps

 

 

 

[peter_spy 1522]

That wiki article needs to be revised as it has some big misconceptions and might put wrong ideas into newcomers' heads (stuff about speculars, using word "textures" for both actual textures and materials, etc.)

@STRUNK The usual and most simple worflow is:

1. You put your diffuse/normal/specular .tga textures somewhere in yourfmname/textures/subfolders.

2. You create a material defnition for them in yourfmname/materials. A simple definition like the one below would do:

material_name               //can be a material path if you like
{
    surftype15
    description stone
    
    
    qer_editorimage      textures/texture_path             // can be a diffuse texture
    bumpmap                textures/texture_path            // normalmap, not bumpmap
    diffusemap               textures/texture_path 
    specularmap            textures/texture_path 
    
    
            // TDM Ambient Method Related
        {
                if (global5 == 1)
                blend add
                map          textures/texture_path       // original diffuse texture goes here
                scale       1, 1
                red         global2
                green       global3
                blue        global4
        }


}

3. Refresh materials in your editor and apply a new material using Media browser.

4. Test your material in-game and tweak if necessary.

5. With your final result, compress diffuse and specular to .dds, leave normalmap as .tga. DDS textures need to have mipmaps generated to show in-game.

6. Put your dds textures in dds folder using the same path as for tga, so yourfmname/textures/subfolders/texture.tga becomes yourfmname/dds/textures/subfolders/texture.dds. You don't have to change anything in your material definition, the engine will recognize textures in dds folder and use them first.

7. Now you can delete your .tga diffuse and specular textures.

[STRUNK 270]

28 minutes ago, peter_spy said:

2. You create a material defnition for them in yourfmname/materials. A simple definition like the one below would do:

So I paste this into a textfile, change the names and texture_paths to where I put the .tga and .dds files .. and probably change "description stone" to a proper description, for it's not gonna be stone, and then save it and just change .txt to .mtr .. right?

I just found that I can open .pk4 files with winrar and look at the folder structure and such from existing fms to have an example.

Thanks a lot. I should be able to get it working now : )

 

[STRUNK 270]

@peter_spy

Some things work now; the "texture" shows up in darkradiant in "other materials/strunk", so that's already very good! But .. although the .tga and .dds file have an alpha channel, when opened in gimp, they don't have it in darkradiant nor in-game ... although I used DTX5 for the .dds ..

Material definition:

STRUNK/trees_backdrop               //can be a material path if you like
{
    surftype15
    description trees
    
    
    qer_editorimage      textures/backdrop/trees_backdrop           // can be a diffuse texture
    bumpmap              textures/backdrop/trees_backdrop            // normalmap, not bumpmap
    diffusemap           textures/backdrop/trees_backdrop
    specularmap          textures/texture_path
    
    
            
    
    
            // TDM Ambient Method Related
        {
                if (global5 == 1)
                blend add
                map         textures/backdrop/trees_backdrop       // original diffuse texture goes here
                scale       1, 1
                red         global2
                green       global3
                blue        global4
        }


}

 

Edited October 6, 2019 by STRUNK

[peter_spy 1522]

Alpha channel won't be visible in DarkRadiant. Also, depending on what kind transparency you need, you have to set it up in the material. If you need 1-bit "alphatest" transparency for the trees, you need to declare it in the diffuse image stage. Replace the diffusemap shortcut with:

{

blend diffusemap

map     textures/backdrop/trees_backdrop

alphatest .5

}

Where alphatest is the cutoff level for transparent pixels. Start from 0.5 and increase or decrease as necessary.

[STRUNK 270]

@peter_spy

 

Sounds good .. only " If you need 1-bit "alphatest"  transparency for the trees, you need to declare it in the diffuse image stage. Replace the diffusemap shortcut with:  etc"  still does not compute in my brain yet : )

Could you add that in the right place of my material definition and paste the result here?

Thanx for all the effort by the way. I really appreciate that, all of you.

 

Edited October 6, 2019 by STRUNK

[peter_spy 1522]

Sure, just replace this:

diffusemap textures/backdrop/trees_backdrop

with this:
 

{

blend diffusemap

map     textures/backdrop/trees_backdrop

alphatest .5

}

 

Keyword

diffusemap textures_texture_path

is a shortcut for:

{

blend diffusemap

map textures/texture_path

}

You use the former when you just want to define a texture path for the diffuse slot. If you want to add some more parameters, you need to use curly brackets, define the image stage mode, provide texture path, and then add other parameters. It works the same way for other textures (normal map, specular map, masks, emissive textures, etc.).

Edited October 7, 2019 by peter_spy

[Geep 247]

I'm having some difficulty getting the trigger_look script to work as advertised. I posted the original problem a while ago to 
http://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/page/17/

but crickets there. To restate more precisely and fully:

---

I'm trying to use the trigger_look script for the first time. I want my player to look at a rope (the seen-object) and stuff happens, limited to popping up a GUI message initially. So, as the instructions for this specified:

- I put a copy of "trigger_look.script" into my <fm>.maps folder

- I added #include "script/trigger_look.script" to the head of my <fm>.script file

- To my rope object I added spawnarg "scriptobject" with value "trigger_look", as well as a "trigger" to a pop up gui message. The popup is working OK... the problem is under what conditions the popup occurs.

When my player looks at the seen-object, the trigger works fine based on the default distance and "once"=1. What does not work is the view direction (just using default, or even with a specified "tolerance" value), which is ignored (e.g., as if "tolerance" was "2" aka 360 total degrees). I can back my player up to the seen-object, and still it triggers when within distance. I've also noticed a console warning about divide by zero in line 66 of the script. Presumably this is the call to the length function

float length(vector v) {
    return sys.sqrt(v_x*v_x+v_y*v_y+v_z*v_z);
}

Perhaps sys.sqrt is broken? This is under TDM 2.07/Windows 10. 

---

I tried further diagnosis of this today, but I'm getting nowhere. Not even sure my copy of trigger_look.script within my "maps" folder is being called, as opposed to some other mystery location. The instructions say to use

#include "script/trigger_look.script"

which I did but the "script" part of the path must be some abstract location... and if I remove "script/", runtime TDM complains about not finding the script.

If I add sys.print(...) in various locations within my copy of the trigger_look.script, nothing extra appears on the console, even it I create a separate threaded child function. That's why I'm thinking some other copy of "trigger_look.script" is being utilized. Or sys.print only works when called by $player1, not from scripts associated with other objects?

Thanks for any help

 

[Geep 247]

Should have added, the instructions for this were found at

http://wiki.thedarkmod.com/index.php?title=Triggering_events_when_looking_at_something

plus comments in the forum referenced above. The forum contains 2 versions of the trigger_look.script file. I used the more recent.

[Geep 247]

OK, poked around further and found that trigger_look is included in the standard distribution as tdm_base01\script\trigger_look.script.

So that's the copy that's being called, and presumably giving the divide by zero error.

[Destined 614]

I am using this script in my current WIP, but have not played around with the parameters too much. One difference I noticed is that I have created a folder "script" in my FM folder and put the trigger_look there. In order for TDM to use modified files over the stock files, you have to mimic the folder structure of TDM in your FM. So I would try to create a "script" folder in your FM folder and put it in there. Also, I have put the #include "script/trigger_look.script" not into the FM's script, but into a file named "tdm_custom_scripts.script", which is also located in the script folder. I hope this helps.

[Springheel 4628]

I used the script in A New Job in more than one place, if you're looking for a reference.  Haven't noticed if anything is broken in 2.07.

 

[STRUNK 270]

About sound being heard through walls, and visportals.

I sealed off the room with caulk, and where doors are sealed the openings with vis portals. My transparent doors I gave the additional spawnarg "transparent"  1. And it all works as it should now ... but ... do I have to do the caulking?

I noticed going through this process that my visportals weren't totally touching the floor, that I copied and made into caulk, but were touching the doorframe model. So an other question is: do visportals need to touch worldspawn, func_static, or models to work as visportals?

Edited October 8, 2019 by STRUNK

[grayman 2967]

Filter out all entities, decals, clip, and patches.

that should leave you with worldspawn brushes.

visportals must seal to the worldspawn brushes. 

it’s ok if visportals stick into the void.

it’s ok if the visportal face shares a worldspawn brushes face.

it’s ok if a visportal face sticks into a brush.

some mappers swear the last 2 ‘rules’ are illegal, but I’ve never had problems with them.

[Springheel 4628]

Visportals have to touch non-transparent worldspawn.  I typically filter out all entities when working on visportals.

(ninja'd)

[STRUNK 270]

@grayman @Springheel

You are fast today : ) Thanks for this basic and essential info!

So if I had done that I wouldn't have to seal the whole room with caulk for the sound to stay in the room?

[grayman 2967]

I don’t know how to answer your question since I haven’t seen what you’ve done

[STRUNK 270]

@grayman

If I would have all the visportals touch worldspawn, as they should, the sound would also stay in the room .. right?

 

[Springheel 4628]

There's nothing special about caulk in regards to visportals--any worldspawn brushes will do.  Sound cannot travel through worldspawn brushes, regardless of type.  It does travel through open visportals.

 

I'm pretty sure I have something about sound propogation in my New Mappers tutorial series, though I can't check where atm.

[grayman 2967]

The wiki has pages that cover sound propagation.

Simply put, if you have visportals in your map, and the sound emitter is at point A and the listener is at point B, think of running a string from A to B, following the natural "path" from A to B (along hallways, through door and window openings, through gaps in your worldspawn brushes, etc.), then pulling the string taut. The string should tuck up against the edges of all visportals it runs through (or pass through the portal somewhere away from the edges, depending on the architecture). A's sound will propagate along the string.

You can see a picture of propagation in the "Sound Propagation" section on this page. (However, the picture shows the sound traveling through the center of the visportals, which is WRONG. The sound for those examples would run through the southern edges of the portal faces.)

 

[STRUNK 270]

@grayman @Springheel

http://wiki.thedarkmod.com/index.php?title=Sound_Propagation:_Part_1

I did read it and it's talking about caulk right away ... I think I'm just gonna test without caulk (and with sealing visportals) to see what happens : )