VTF and light bounce

[ifO]

Ah nice, that's pretty cool, thanks for sharing!

If your aim was to multiply the original reflectivity values, I could actually stick in another option that would do that for you. And would you rather go from VTF to VTF rather than have an intermediate TGA stage?

So I'm suggesting something like:

vtfcmd -reflectmultiply 2.0 2.0 2.0

(to take an existing vtf, multiply it's reflectivity values by 2, and output to vtf)

If you let me know exactly what functionality you want I can try to edit the tool to suit. It shouldn't have to be a fiddly process!

For now I'll take down the link, until I've spoken to Nem or Wunderboy about it.

[robert.briscoe]

what would be awesome would be if i could make say 3 batch files, each with a command line parameter which specifies the multiplier (as you mentioned above) and just be able to drag and drop any vtf onto the .batch files and it updates the dragged vtf. Kinda like how I compile my models atm. Each folder with my qc files in has a batch file for studiomdl that looks like this:

@echo off

"%sourcesdk%\\bin\orangebox\bin\studiomdl.exe" "%1"

pause

and i just drop the qc onto it to compile my models no matter where they are.

What do you think? possible?

[ifO]

Shouldn't be a problem, I'll take a look at it this wkend

[robert.briscoe]

awesome thanks!

[Wunderboy]

Nice work

[ifO]

Done'd. PM'd

[Ezekel]

I know I'm raising a necro'd post here, but did anything actually come of this?

As far as I can tell Nem's tools don't mention this being added in the revision logs.

The images posted look really impressive and I'm sure I'm not the only one who'd like to be able to make use of the resulting indoor ambience.

[Minos]

I know I'm raising a necro'd post here, but did anything actually come of this?

As far as I can tell Nem's tools don't mention this being added in the revision logs.

The images posted look really impressive and I'm sure I'm not the only one who'd like to be able to make use of the resulting indoor ambience.

As Robert said, you need to tweak the RGB values on a per-material basis. I made some tests with this before and it proved to be unpractical. It's easy when you have only one texture (which has only one color really, such as the dev texture) but it's just a lot of work when you have more textures, all with different colors. Keep in mind that the RGB values bounced by the vrad tool are not the RGB values in each texel but an averaged value for the entire texture. So let's say you have a texture which is half green and half red, the color bounced by this texture map will be an averaged value from both colors, not green and red as one would expect. These RGB values are calculated when you generate the VTF and can be accessed by opening VTF files on VTF edit.

This is the kind of stuff that should be done via an improved lightmap generator and not on a per material basis. I wonder why valve never updated vrad, it seems so trivial to be honest. I mean, 3rd party Quake 3 rad tools have supported ambient occlusion and shit like that for years now...

[Jenn0_Bing]

Maybe this can help? http://www.nodraw.net/2011/02/reflectivity/

[Minos]

Maybe this can help? http://www.nodraw.net/2011/02/reflectivity/

If you use values such as .5 .5 .5 etc that means your texture map is gonna bounce white color only.

[Ezekel]

i guess it might be down to the fact that they've never needed it to do more than it does.

most probably, originally the limitations we see today were there as a design decision based on considering the time that would be needed to compile an average map on hardware that was around in the hl2 days vs how much of a difference it'd make to the result.

as far as i can recall of valve games (even the newer ones like the l4d series) there aren't really any cases where a scene demanded much from indirect ambient lighting. - so i guess it's just down to an "if it's not broke don't fix it" mindset together with the LD only focusing on scenes that won't suffer from the shortfalls of the system.

i've found a bit of success though by mixing together the suggestion about the vmt reflectivity values together with the -extrasky compile option on vrad.

Maybe this can help? http://www.nodraw.net/2011/02/reflectivity/

If you use values such as .5 .5 .5 etc that means your texture map is gonna bounce white color only.

from what i've read, the reflectivity values are a multiplication of the base values of the vtf, so .5 .5 .5 for a surface that is pure red should bounce rays that are pure red at 50% intensity of incident

[Minos]

i guess it might be down to the fact that they've never needed it to do more than it does.

most probably, originally the limitations we see today were there as a design decision based on considering the time that would be needed to compile an average map on hardware that was around in the hl2 days vs how much of a difference it'd make to the result.

as far as i can recall of valve games (even the newer ones like the l4d series) there aren't really any cases where a scene demanded much from indirect ambient lighting. - so i guess it's just down to an "if it's not broke don't fix it" mindset together with the LD only focusing on scenes that won't suffer from the shortfalls of the system.

i've found a bit of success though by mixing together the suggestion about the vmt reflectivity values together with the -extrasky compile option on vrad.

Maybe this can help? http://www.nodraw.net/2011/02/reflectivity/

If you use values such as .5 .5 .5 etc that means your texture map is gonna bounce white color only.

from what i've read, the reflectivity values are a multiplication of the base values of the vtf, so .5 .5 .5 for a surface that is pure red should bounce rays that are pure red at 50% intensity of incident

That's incorrect. The reflectivity value overrides the VTF values.