Sunlight lighting a room?

[-Dash-]

I've attempted to make a room with three medieval windows. I would like sunlight to pour through the windows from the skybox to light the room.

My problem is, no matter what attributes I change for the skybox only a paltry amount of light pours in. Even if I increase the values A LOT, still not enough light pours in, and the buildings exteriors look completely white because it is so bright.

Any suggestions?

[obsidian]

Screenshot? Do you have glass in the window? Check shader for window and alpha channel? Something is probably reducing the amount of light that is able to enter the room.

[Silicone_Milk]

I'm curious to see your editor and compiler settings.

Enabled -bounce in the light compile stage?

Also, Obsidian nailed what I wanted to mention also - texture could be reducing light. Make the windows just simple holes if they're not already and see what happens.

[-Dash-]

I'm at school, so I can't post the GTK radiant screenshot.

It's a medieval crosshatch window, like this:


I forgot to put glass in the holes. Right now the wood material (the crosshatches and border) are brushes, and sunlight is supposed to go through the holes to light the room.

So, how would I set up glass and an alpha channel using shaders? I've just been learning Shaders, and they are a pain in the ass.

Last of all. You have both been helpful, more than you can expect from most forums.

Ps: How do I enable bounce?

[-Dash-]

If you are so inclined, would you help me with one more question?

How would I export a ASE from 3DS Max, what's the proccess?

[obsidian]

So, you don't actually have anything physically blocking the window other than the brushwork?

Is the sun's directional lighting actually pointing through the window? It won't work right if your sun is on the opposite side of the building from the windows. Maybe it'll be easier to just use a spotlight.

-light -bounce N, where N is the number of bounces, typical values are 2-8. Higher numbers requires a much longer compile time, for testing, I tend to use low values, 2 or 3. Use 8 for a final compile.

[obsidian]

3ds Max. File > Export.

If you are wondering how to get the materials working properly in game, it's a little more involved than that. You can set it up directly in Max or edit the .ASE file in a text editor to point the materials to the texture/shader.

Unfortunately, the old UBB archives are sitting on a DVD archive on DooMer's desk and he doesn't seem inclined on restoring them, so my old tutorial isn't working. But here are the screenshots, you should be able to figure it out from that:

[Silicone_Milk]

hmm... off the top of my head I think it's something like
"q3map2.exe light -fast -bounce 6 -dirty -sky 3"
Obsidian would know the proper arguments for a decent looking build though.

See: http://en.wikibooks.org/wiki/Q3Map2


What the hell Obsidian I get up to go to the bathroom and you beat me to the reply by 20 minutes.

[shio]

http://q3a.ath.cx/?editing=aseexport

@obsidian: some steps aint really needed, like renaming the diffuse-channel

[Hipshot]

http://q3a.ath.cx/?editing=aseexport

@obsidian: some steps aint really needed, like renaming the diffuse-channel

Sometimes, when not renaming the diffuse channel, the ase will think the diffuse is the shader name and it might not find the proper shader, only a diffuse texture (and if the diffuse is placed wrongfully, like c:\image.bmp, it will not find any correct image at all and it will show a missing texture image).
If you don't feel like naming the diffuse, you could always just deactivate the diffuse before exporting to make sure the ase uses the shader (material) name, instead of the diffuse.

edit: Note to self, seems it's a bug when compiling with Q3map2_fs_20g, the paths works perfectly with Ydnars Q3map2, whatever the name of the diffuse channel.

[shio]

Sometimes, when not renaming the diffuse channel, the ase will think the diffuse is the shader name and it might not find the proper shader, only a diffuse texture

i know what u mean, but that was probably because u added .tga .. so he would use the bitmap instead of the shader.
i tested it back then and it doesnt matter if u have something inside the diffuse channel at all.
i know its different for doom3 or other games, but for q3 only the material-name matters.

[obsidian]

Silicone_Milk: You snooze you lose! (Beat you on your first reply, too)


I don't recall the details, but the way the editors (GtkRadiant 1.4.0 and prior, and GtkRadiant 1.5.0) and Q3Map2 all read different parts of the material list. In my tests, it was the only way to get maximize compatibility. Anyway, there's no harm done in setting the diffuse value if a bit redundant.


Test Compiles:
-light -fast -patchshadows -bounce 3 -gamma 2 -compensate 4

Final Compile (tweak as necessary):
-light -fast -patchshadows -samples 3 -bounce 8 -gamma 2 -compensate 4 -dirty

[-Dash-]

Now I forge ahead.

The model export worked magically.

Two questions appeared. How can I increase details for textures? In Sock's terrain tutorial, the detail was extremely sharp. However, he noted it was only editor pre-rendering. Is there someway to condense textures to 1/4 the size, creating more detail?

Would the easiest way be to convert a 512x512 texture to 128x128, or?

Last of all, how can I turn a model into brushes in the editor?

More questions to come.

I'm beginning development on a medieval modification, so any help will profit when you get to play it

Merci.

[Silicone_Milk]

Scaling textures from a high resolution to a lower resolution will only cause you to lose detail in the texture.

Think about it, if you have 512 x 512 pixels and shrink it to 128 x 128 pixels you've lost 384 x 384 pixels of texture.

To get high detail you'd generally use a higher resolution texture such as a 1024 x 1024 texture. 512 x 512 is pretty standard for Q3 though.

It really depends on the quality of the texture and the ratio at which it's applied to the geometry.

If you take a 512 x 512 texture and stretch it to fit a face of a brush that is twice as big as the texture's size, then you've essentially magnified the texture so things become blurry up close.

The best thing to do to retain detail is to build your geometry with your textures in mind. Build the brushes to fit the textures. (Stretching isn't actually too big of a deal but I'll leave that for somebody else to point out and elaborate on).

[Silicone_Milk]

You'd also probably be interested in visiting http://www.katsbits.com The site is all about Quake 3 (idtech3) development with external modeling applications (specifically Blender but the concepts can be applied to other applications as well).

There's a particularly useful article on ASE models and how to build a level out of them.

What I'm getting at is, do you really need to convert your ase model in to brushes? I only see things getting really messy really fast.

[dONKEY]

Brushes are pretty dead these days....go the model route.
Not having 3DS I always hand hack my ase files once exported from blender.
The default texture scale for radiant is 50%. A 512 pixel image ends up 256 game units. You can decrease the scale though, so a 512 pixel image is 128 game units. That way texture resolution can be improved. Just bear in mind though big 1024 textures can be over a mb each.

[obsidian]

I think by "condense" he meant "scale", in which yes, you can. In GtkRadiant, select a few faces and hit "s" to open the surface inspector. From there you can scale you textures as needed.

Default value is a normalized value, 0.5 (which dONKEY pointed out is 50%, or 2 pixels squared for every game unit squared). A value of 0.25 would be twice as "sharp".

Brushes are rather simplified solids, if you're building something as a model, it's usually better off staying as a model since they are generally more complicated (higher level of vertex point precision, etc).

[-Dash-]

Tres bien.

Scaling textures sacrifices detail, I see. That is why of course that Quake 4 textures are 1024 x 1024. So... I will use that size.

And then I can use the Surface Inspector to condense them into higher resolution.

After reading Kat's tutorial I have understood that you use Blender to export model into map format so that the models become solids. So it would seem I would create the map in 3DSmax, export as ASE, load it into blender and then export it to .map.

To conclude.. Are models less of a resource hog than brushes, is that one of the benefits?

Thankyou everyone for the valuable replies.

[Hipshot]

I would not turn models into brushes, instead, cover them with playerclip and/or weapclip and also botclip. Or, if it's a simpler model, like a terrain piece, use spawnflags 2 to make it solid.

[obsidian]

Quake 4 is a much newer engine, capable of running with much larger textures on newer hardware with acceptable performance. Quake 3 is not. I would be wary of using entirely 1024 textures, opting for something more conventional with a mix of 128, 256 or 512. Only use large textures if you really need them, they come with a memory and performance impact. After a certain pixel density, things will just get mipmapped out of existence anyway.

If you're just building walls and stuff, just use GtkRadiant. Don't make them in a modeling program, don't try to convert models into brushes. Stop trying to make your life more complicated than it really is. Use models only for stuff that require high polygons, off-grid vertex points, or other more complicated stuff that you can't build with brushes. Brushes are highly optimized and you will certainly still need them for the entire -vis process from which models are completely ignored.

If you try to develop some crazy work-flow outside of the norm, don't expect people to be able to help you afterwards if something doesn't work, since it will be outside of our area of experience. Especially if you are completely new to all of this.

[Silicone_Milk]

Obsidian brings up many good points and Hipshot offers some sage advice.

If you're doing axial geometry use brushes. They'll make life so much easier in the world of BSP levels. Plus, the q3map2 compiler is smart enough to fix some errors in geometry with brushes. If I remember correctly, it leaves ase models "as-is".

By converting a model to a brush you're going to get some super ugly results (vertices aren't on the grid, impossible to manage) that would take hours upon hours to clean up and optimize.

Something to consider would be to create basic rooms (literally just 6 brushes. A box for a room) out of structural brushes and then load in .ase models to sit within the box to act as the visuals. The structural brushes will create some decent vis splittng and keep your map from leaking. Then you can play with models all you like.

Just, don't convert the models to .map format. The results are not pretty. I speak from experience.

[dONKEY]

The other thing about the blender to map route is that the script produces some less than desirable results. I thought I could use this script to produce some brush collision maps for models. But I actually spent more time trying to tidy up the exported brush work than it took me to make a collision map out of clip brushes in radiant.