Ungoliant's mapping questions

[ungoliant]

it was my guess that textures/darkmod/sfx/grey_mid was along those lines. it didn't work. And if the problem is using _white or _black, then there's definitely a whoooole lot of textures that are gonna be needin some new specmap lovin' for 1.04.

[Serpentine]

it was my guess that textures/darkmod/sfx/grey_mid was along those lines. it didn't work. And if the problem is using _white or _black, then there's definitely a whoooole lot of textures that are gonna be needin some new specmap lovin' for 1.04.

 

(0) _black will give you no specular

(255) _white will give you the most specular possible (and as you know, that's quite a bit)

(127) mid_grey will give you a shitload of specular

 

You're looking for something around 10

 

On the other hand if you upload a pack of the material+relevant textures I can sort it out tomorrow.

[ungoliant]

yeah well after trying _black with the same results as _white, i kinda figured there was a problem.

 

Anyway heres the pk4 i made with the relevant files:

fence.pk4.txt

[rebb]

Example

Reduce the size by half...

 

textures/half_size 
{
{ blend diffusemap map scale(textures/decals/plasma_burn.tga, 0.5) }
}

 

reduce size...? that doesn't sound like it does what I want it to do.

 

Yeah, because thats not what scale() does ...

scale() scales the RGBA Values of an image.

 

So anyway, i went ahead and used just plain old textures/darkmod/sfx/grey_mid as the parameter. No change. Still stark white specular. Now i'm really pissed off. I use _black. NO CHANGE.

 

I mentioned that he specular looks like it comes from the main light.

Did you actually put _black into the standard specularmap slot of the material ?

And is the overshininess gone if you set the global ambient value to 0 0 0 ?

 

Perhaps a specialist should be called in. This might be something that is affecting all textures, after all, hasn't everyone been noticing the "shiny shiny" aspect of textures since 1.03? my grass, in the pitch dark, ambient world settings 0.04, 0.04, 0.04 is.... shiny. somethin' is up.

 

Yes the new shaders ( including ambientEnvironment.vfp ) use a strong fresnel effect that causes a shiny look.

It also assigns a base specular value to everything.

We can probably tone that down.

 

Edit :

 

After doing some local tests with the fence_iron_01, it looks like the "rgb 0.1" does not actually adjust the specularity.

Putting "rgb 1" looks exactly the same as "rgb 0.1" in that stage.

 

Putting the grey_mid texture scale()'d to about 0.25 does have an effect however, and makes the specular response look similar to how it looks when the default Doom3 interaction is switched on. ( TDM fresnel will still cause edge shininess at grazing angles tho )

[ungoliant]

that is great news! thanks for the help, rebb

[ungoliant]

couple of questions, relating to the elevator + rotating gear problem posted previously.

Happened to run across this spawnarg that is inherited by atdm:mover_elevator, called control_gear_direction, set by default to 1. Here is the description: "Set this to 1 to let this mover control the direction of targetted rotaters, depending on whether the mover is moving forward/backwards."

 

Even though this spawnarg defaults to true on my elevator, the func_rotating that is targeted by my elevator uses its default behavior of rotate cw, stop, rotate ccw, stop, rotate cw, stop, etc etc. It only stops and changes direction every time each time targeted. Is there a way that I can delegate control of the rotate direction to this spawnarg? perhaps there is another idRotater entity that would work better with this?

 

That leads me to the second question: where can I find the code to the idRotater spawnclass? If I can't get anything else to work, maybe theres some methods in there that i could call with a script to control the rotate direction manually (if its even possible to control entities that way).

 

edit: oops i'm foolish. that spawnarg works perfectly. however the timing issue still exists. Also i found the scriptevents needed in doom_events.script as well, perhaps that might fix the timing issues. Out of curiosity, i'd still like to know where the code to the spawnclasses resides at so i could take a peek.

 

re-edit: found idRotater in mover.cpp, *whoosh* is the sound of most of it going over my head. i think i'll stick with working with just the scripting events for now.

Edited February 27, 2011 by ungoliant

[Fidcal]

It might be possible to use a script to reset the cog just before each rotation, eg,

 

void resetCog()
{
   $cogname.setAngles(0);
}

 

I'm not sure without checking if I got the syntax right but I think it's just a single argument. And of course, 0, could be whatever angle it starts at if different. I expect it would give a little jerk as it starts but it should start in sync.

 

But I could be completely wrong. If it starts late anyway then resets itself it won't help.

[ungoliant]

It might be possible to use a script to reset the cog just before each rotation, eg,

 

void resetCog()
{
$cogname.setAngles(0);
}

 

I'm not sure without checking if I got the syntax right but I think it's just a single argument. And of course, 0, could be whatever angle it starts at if different. I expect it would give a little jerk as it starts but it should start in sync.

 

But I could be completely wrong. If it starts late anyway then resets itself it won't help.

 

the rotation does not start late, that part works fine, its the stop rotation that lags. Your syntax is correct, and that event can be set to any entity, not just movers, which is nice. Here is the description:

 

// Sets the current orientation of this entity (relative to bind parent if any).
scriptEvent	void 	setAngles( vector angles );

 

not sure about the vector parameter there, i forget how those work.

The others i've seen and have been thinking about are:

 

// Stops any rotational movement.
scriptEvent	void 	stopRotating();

 

or

 

// Disables the mover/trigger
scriptEvent	void 	disable();

 

Theres a few others that would be much harder to set correctly, but would have much better precision. I'll probably try these out first though

[Fidcal]

I've got a similar problem now. I have func_rotating 10 tooth cog driving a 16 tooth cog. The 10 tooth is speed 60 so I reckon the big one should be 10/16ths of 60 reversed which is -37.5. But it gets out of sync - and it seems to get more and more out of sync so it's not just a start lag as far as I can see. How would you calculate that?

[Fidcal]

Calculating this another way, the 10 tooth rotates 360 degrees in 4 seconds so one tooth rotates 36 degrees in 4/10ths of a second. The 16 tooth needs to do the same but its teeth are 360/16 = 22.5 degrees apart. mmm.... so its speed should be 22.5 * 10/4 = 225/4 = 56.25. I'll try that but it seems unlikely.

[ungoliant]

Calculating this another way, the 10 tooth rotates 360 degrees in 4 seconds so one tooth rotates 36 degrees in 4/10ths of a second. The 16 tooth needs to do the same but its teeth are 360/16 = 22.5 degrees apart. mmm.... so its speed should be 22.5 * 10/4 = 225/4 = 56.25. I'll try that but it seems unlikely.

 

ooh ooh, i know this one

 

my timing doesn't really get out of synch while running, my speeds are aligned accurately to the .00001's place, and it only runs while the elevator is in use.

 

using a little basic physics for each cog, assume each has its own equation, v = d / t. Assume 2 things, time is constant between each cog, and set an assumed velocity (speed spawnarg in doom units/s) for only 1 cog. You are given distance for each cog, i use angular distance between each tooth in the cogs. As an example I will set cog1 with an arbitrary velocity of 10 doomunits/s. Here is the setup.

 

cog1: 10 = (360/10) / t

cog2: v = (360/16) / t

 

solve cog1 for t. plug in solved t value for cog2, solve for v. set your cog2 speed spawnarg with solved v value, and now your speeds are aligned, have fun!

 

edit: the reason you're getting yourself into trouble there is you are setting your time to the amount of time it takes for the gear to do a full rotation, but your distance is set as the amount of degrees between teeth.

Edited February 28, 2011 by ungoliant

[Tels]

the rotation does not start late, that part works fine, its the stop rotation that lags. Your syntax is correct, and that event can be set to any entity, not just movers, which is nice. Here is the description:

 

// Sets the current orientation of this entity (relative to bind parent if any).
scriptEvent	void 	setAngles( vector angles );

 

This is very probably pitch, yaw, roll (e.g. 3 angles), but I am not sure onthe exact order, would need to look into the code.

[ungoliant]

This is very probably pitch, yaw, roll (e.g. 3 angles), but I am not sure onthe exact order, would need to look into the code.

 

ohh yes more physics 101 coming back to me now(slowly). vector is addition of movement on 3 different axis added together. but i thought that these things were used to calculate both angle and distance. and whats up with the yaw/pitch/roll thing? whats wrong with x/y/z?

[Fidcal]

I work that out to 37.5 which is my original value. By trial and error the true values seems to about 40 but why I don't know.

[ungoliant]

60 = (360/10) / t --> t = 0.6

 

v = (360/16) / 0.6 ---> v = 37.5

 

hmmm... this value doesn't work...? hmmm my DR doesn't work right now due to moving things around and deleting stuff getting ready for format. is it possible that this could be due to the size of the models? if speed spawnarg is linear velocity in doomunits/s, i suppose this is possible. Is there a spawnarg that works on angular velocity? something like radians/s, degrees/s or a time-based spawnarg on how long it takes to do a full rotation?

 

I forget if my gear uses some sort of angular velocity, can't open DR to find out... I know mine works perfect, and it is a linear shaft that moves straight up/down connected to a gear that rotates, and the formula worked perfectly, so 2 rotators shouldn't have any trouble.

[Serpentine]

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

 

Just an extra note - I've noticed that cog setups can have quite a nasty habbit of eating performance even when completely out of view etc. If you don't need them to be blockable for some reason, I'd suggest clipping them off and making them non-solid, tho I haven't checked it it actually helps. I'd also imagine binds and func_statics might also be quite costly compared to true models. As said, I'm taking a few wild assumptions here

[ungoliant]

thanks for that link, serpentine. At least now I know I can blame this Euler asshole for the " Z Y X " format on a lot of spawnargs.

[ungoliant]

got dr working again, had to reinstall VC++ 10 runtime components.

Good news and bad news, fids.

 

Ok the bad news is that I checked out speed, and apparently its already set up for degrees/s. Looking over the equations again, it doesn't look like theres any unit type errors or anything. v is in degrees/s and d and t are in degrees and seconds. So.... it should work, but it doesn't, i guess.

 

The good news is i totally just figured out my problem! And possibly your problem as well, depending. mover_elevator uses a default spawnarg of "decel_time" "0.2". This means that the during the last cycle, the linear speed of my elevator shaft is off-key. Haven't tried it yet, but i'm almost positive that setting that to 0 will fix my problems. So, have you set any acceleration or deceleration on your gears, or do your entities have any defaults set? this might be a factor. try it out.

 

edit: it works, it works!! huzzah! now i'm excited

Edited February 28, 2011 by ungoliant

[ungoliant]

I have one last solution to offer, fids, I was just checking out the models. One mistake i made early on was miscalculating the distance between teeth on my elevator shaft... so i figured maybe.... well, anyway I looked through the model list, and if you are using gear_large_hollow_5_spoke, that model has 15 teeth not 16. i counted 16 twice before realizing that i messed up, and that there were actually 15 teeth on that thing.

 

edit: just recalculated. guess what the adjusted speed is? 40

Edited February 28, 2011 by ungoliant

[Fidcal]

Ah - you're right. In camera view I counted 4 in the first quarter then too smart for my own good to count the rest I glanced to see it was symmetrical and assumed 4 in each quarter. In grid view it's easier to see that tooth 4 is not exactly at 3:00 o'clock as I thought. So 40 makes sense now. Thanks.

[ungoliant]

audio question: using audacity to cut up some tracks from freesound.org, but having some trouble. I've converted to mono 16 bit already, and got my selection laid out. However, I can't seem to find a way to convert the track to 44100Hz from 96000Hz without the track doubling in length and sounding real slow. Is there a way to force a track to keep its original timing after converting to a new rate? Also, there doesn't seem to be any way in audacity to force your track to conform to any data rate, like 96kbps. do i need to download a new app to do these things?

[Serpentine]

audio question: using audacity to cut up some tracks from freesound.org, but having some trouble. I've converted to mono 16 bit already, and got my selection laid out. However, I can't seem to find a way to convert the track to 44100Hz from 96000Hz without the track doubling in length and sounding real slow. Is there a way to force a track to keep its original timing after converting to a new rate? Also, there doesn't seem to be any way in audacity to force your track to conform to any data rate, like 96kbps. do i need to download a new app to do these things?

 

It sounds as if you're just changing the sample rate of the clip rather than resampling it. I'm no expert on Audacity or anything, but the one time I have used it to resample I had to change the project sample rate to the desired value and then re-export, in the export options there's a setting as to where you want to take the sample-rate from, this you then change to the project rather than the imported track. This should keep the timing and speed correct. The bitrate you're talking about will only be changed when you're exporting, for example 96kbps will sound completely different depending on the encoding(format), so it wouldnt make sense to have some kind of universal value when editing.

[ungoliant]

thx serp, got it working. project sampling rate wasn't in the menus, it was down at the bottom of the app window, and i missed it completely until you mentioned it

Edited March 7, 2011 by ungoliant

[ungoliant]

moar aggravating problems, yayyy!

 

Another timing issue: I wish to open a door. I wish to check if $doorname.IsOpen()==1. The button that opens the door is also the caller of the atdm:target_callscriptfunction that calls this particular script. the door always starts moving before the script gets to this point, so it always returns true. This check is only necessary directly before the door opens, but I dont know how to time it without operating the whole door via script instead of letting the door do its door-thing-that-it-does. any ideas on how to check if its open before the door starts moving?

[Fidcal]

Not sure what you're doing here but one clumsy suggestion:

 

Set up a global variable at the top of your script file, eg,

 

float g_door_open;

 

Then a couple of events:

 

void door_is_opening()
{
g_door_open=1;
}

void door_just_shut()
{
g_door_open=0;
}

On the door make sure it has:

 

trigger_on_open 1
trigger_on_close 1
trigger_when_opened 0

 

And get the door to target two script callers that call the appropriate event above.

 

Then in your existing script you test the value of g_door_open instead of using IsOpen.

 

No idea if any of that is of any use at all!