I'm having a problem with a light model in my test map:

World model is models/props_urban/light_fixture01.mdl

So I've created 3 versions:

1) prop_static - shows up in a test run

2) prop_physics_multiplayer - shows up in the test run but falls off the wall! Quite amusing when I first tried it :D

3) prop_physics - doesn't show in a test run

I can see the models in Hammer perfectly well, and I'd be happy enough to stick with prop_static, but I want to be able to shoot the light out. And so I want to change the skin from 1 (on) to 0 (off). And I can't do that without naming my object. And there's no 'name' property on a prop_static!

besides, the tutorial I read said I should be using prop_physics - so what have I done wrong?

I've deleted my config.cfg to allow DOD to recreate it, and broken the autoexec link to my fps booster configs, and I'm running DX9 mode with High detail settings. cl_prop_phys_enable is 1.

I've got some barrels and oil drums as prop_physics objects - they appear and 'work' as you'd expect.

Any ideas?


edit: well, it seems prop_dynamic works... but it's odd the tuts mention prop_physics instead. Is there any performance hit, or boost, or should I worry about something else instead?

some models wont work on different prop types. The prop_physics_multiplayer is suposed to fall, whats why its a physics object. if you want it to stay there make it a prop_static, or disable the movement in the flags.

im bad at this next part... if it dont work then it isn t anything you've done wrong my own poopyness in this area:

as for the breakable lights, you need to make a brush, like the glass covering, or just find a transparent brush, that works too. Tie it to a func_breakable, then place a light entity inside the fixture. Name the light something like Light1. now, goto the properties for the func_breakable, and goto the outputs. Click the "add" button
set the my output name to OnBreak, the Targets Entities named: Light1, Vie this input: TurnOff

that should work to make it go off.

In the flags tab for the prop_physics_multiplayer tick starts asleep this way it won't fall or move until hit by a bullet or so on.

Maybe try making the prop_static version a prop_dynamic in order to name it so you can change the skin on it, though I thought prop_statics had name boxes? Ohwell I haven't got hammer on my mums laptop to look at :(

Are you ever lucky that I drank a bucket full of coffee earlier and can't sleep.

Anyway.

Use prop_physics_multiplayer.

Give it a unique name, something like "Chuck" will do.

Under the Class Info tab, set the "Health level to override motion" to something low like 1 or maybe 5, and do the same for "Physics impact force to override motion".

Now, under the Outputs tab, add a new entry.
Set 'My output named' to "OnHealthchanged"

Set 'Target entities named' to "chuck"

'Via this input' to Skin

'With a parameter override of' to 1

I'm not quite sure if this will cause it to change skin when hit by another physics object as well. If it doesn't, change the 'My output named' to "OnMotionEnabled".

It all works with prop_dynamic, all except my gib shooter doesn't shoot out anything, and hl2 goes into a loop trying to pre-cache the breaking glass sound.

Still, I'm sure that's fixable!



The tut is at: http://www.akilling.org/akg/tutorials/wiseLightShot.asp

I didn't follow it exactly - maybe the model I chose doesn't go with prop_physics, as PanFrie suggested...

Thanks for the replies!

This is the first night I've really made some progress on my little test map... I've done something interesting with lights, made some telegraph poles with cables, and got the environment lighting on my map to work. Add in a better understanding of displacements with blends (and alpha painting) and I really feel I've got somewhere (at last!).

I can feel a new addiction taking hold :p



Next dumb question....

how do I control the angle of the camera when the map starts? I'm not sure what entity I need (I've searched but get too many hits that don't help :()

prop_dynamic is really the best way for lamps attached... assuming you don't want them to swing back and forth.

That way you can change the behavior based on a switch or shooting it or whatever...

There's a good tutorial on this right here:

http://www.akilling.org/akg/tutorials/wiseLightShot.asp

point_viewcontrol

how do I control the angle of the camera when the map starts? I'm not sure what entity I need (I've searched but get too many hits that don't help

point_viewcontrol is the one! I never heard of it, but I found it in the Flash example map and says to myself, I says, "whatthahellisdiss?" and one thing led to another. :D

No more looking at the ass-end of your map on game start!

You can actually place mulitple ones of theese and give ppl a slideshow of your map while they choose a team

Thanks guys!

point_viewcontrol for teh win ;)

Next question / problem:

My water ain't working properly :(

I made a big brush, textured with dev_water2 and it shows up (as cheap water) in Hammer.

When I run the map, the surface doesn't display, but if I shoot it I get splashes. If I jump in it and submerge, it works - I see water and bubbles and get the sound effects (until I hit the bottom, then the sound stops)

Is it because the base of my 'swimming pool' is a displacement, and the water brush is clipping into it?

I've got a water_lod_control and env_cubemap in my map, I made sure all faces but the top one are nodraw.

On the tuts it seemed so straightforward :(

Originally posted by Ol' Noodle Head
No more looking at the ass-end of your map on game start!

Roflmao, if only more mappers would use this handy entity

try another water texture :)
the dev_ one might be here for testing purposes I guess...

youre not supposed to get errors when using displacement with water.

try to get your water block's size as close a possible to the "pool" its supposed to be in though,it prevents the engine from drawing unused water surface.

I'm a twit... I had a model sticking through out through the base of my map (thru the nodraw) *and* through the skybox. Damn those tree models, they're so big!

Once I expanded my skybox it worked perfectly.

I found it surprising that bullet splashes travel through the walls of my swimming pool to appear in thin air... ;) I guess I'll map around that 'feature' :p

I'm a twit... I had a model sticking through out through the base of my map (thru the nodraw) *and* through the skybox. Damn those tree models, they're so big!

Was it the poplar tree? If so i feel your pain, I wanted to use a few of those and there they are flying up out of the map. Too bad, they're beauties....if only someone could shrink them a bit.

Right... next daft(?) question:

I really need a gravel / grass blend texture, but when I alpha paint with it and then run the map, I get loads of (rather unconvincing) grass sprites growing out of my gravel road. Is there a way to avoid this happening? Are there alternate versions of the textures that don't sprout "Auto-Grass" (tm)(c) ?

Originally posted by Ol' Noodle Head
Was it the poplar tree? If so i feel your pain, I wanted to use a few of those and there they are flying up out of the map. Too bad, they're beauties....if only someone could shrink them a bit.

It doesn't matter if the top (or bottom) of the props stick out of the skybox. You only need the prop origin to be within the world, the whole prop will be rendered either way.

That is useful info to know, ty.

Yeah, thanks Furyo. Man, this is a great thread. Newbie mappers everywhere rejoice and sigh in relief.

Originally posted by Brooker
Right... next daft(?) question:

I really need a gravel / grass blend texture, but when I alpha paint with it and then run the map, I get loads of (rather unconvincing) grass sprites growing out of my gravel road. Is there a way to avoid this happening? Are there alternate versions of the textures that don't sprout "Auto-Grass" (tm)(c) ?

Either you modify the .vmt of that file to save a new one in a directory called materials/"yourmapfolder"/ and you remove the detailprops line or you can just use another blend :)

Originally posted by KominAaa
Either you modify the .vmt of that file to save a new one in a directory called materials/"yourmapfolder"/ and you remove the detailprops line or you can just use another blend :)

Cheers, I'll bear that in mind!
I'll probably just dig out the nice blend texture I used in my first nice test map, where I wondered why the grass sprites weren't showing, and I was tempted to add it to my list of questions ;)

They need more combinations of blend textures. I found this great tutorial on Snark (http://www.snarkpit.net/editing.php?page=tutorials&game=HL2&id=181) but it's a little over my head (haven't delved into material creation yet)

What I really need is a base of ground/snow01 and some dirt tex for the alpha.

for gravel paths use overlays then i dont *think* you get sprites

Cheers for the replies (and hi, Jack!)

Next questions are about optimisation

1) This is prompted by another thread... ('models improperly lit'). When I have a non-enterable building, with window models applied to the exterior, I currently either make the building hollow, and position the windows 'normally', or I cut (not carve or hollow) holes through the main block to accomodate them. Obviously I ensure all the internal faces are nodraw textured... but is there a performance hit from having hollow buildings? Is there an ideal method of integrating the window models?


2) Grid size. I'm mapping with a grid size of 8 cos I've been led to believe that multiples of 8 is the best for engine performance. But what about the few times in a map when I could do with some fine detail... like making a capping for a wall... can I drop to 2 or 4? Is it such a no-no I should *really* avoid doing it, even though it could improve part of my map?


That's all for now... ;)

Disclaimer: I don't know jack.

1) How do the official maps do it? I know for fact there are plenty of windows on unenterable buildings on the official maps. They look lit fine, so obviously they did something right. Look at flash or decompile the others using vmex.

2) I would reduce gridsize whenever you need to. The biggest downside afaik is increased compile times and maybe slightly lower fps. But as long as you are working in 8 grid most of the time, the difference should be marginal (I'd assume so anyway...). Even the officials don't always abide by the 8 unit grid rule, you know.

Edit: Oh wait -- you may have missed this from the other thread --

Originally posted by El Capitan
Yes. Thats the problem. info_lighting is used to change the origin of the lighting when placed in front of a prop!! Put info_lighting entity in front of them as I said above!

If that's correct, that should help you #1.

Originally posted by Brooker
Cheers for the replies (and hi, Jack!)

Next questions are about optimisation

1) This is prompted by another thread... ('models improperly lit'). When I have a non-enterable building, with window models applied to the exterior, I currently either make the building hollow, and position the windows 'normally', or I cut (not carve or hollow) holes through the main block to accomodate them. Obviously I ensure all the internal faces are nodraw textured... but is there a performance hit from having hollow buildings? Is there an ideal method of integrating the window models?


2) Grid size. I'm mapping with a grid size of 8 cos I've been led to believe that multiples of 8 is the best for engine performance. But what about the few times in a map when I could do with some fine detail... like making a capping for a wall... can I drop to 2 or 4? Is it such a no-no I should *really* avoid doing it, even though it could improve part of my map?


That's all for now... ;)

1)having hollow buildings does not take much more that having full ones,it just creates some more leafs.
Dont be so afraid to make cut on blocks,as long as its clean and you pay attention to what you do...
During the vbsp process cooplanar faces that have exaclty the same texture properties are often merged into one big face so the engine doesnt really care.
So Id say it depends on what window you are working with,flat ones doesnt need cuts but theres no big deal having some with hollow ones.
If you have a really complex scene,go for the flat ones,but the hollow ones look better :p

2)Aside of the paying attention to the 1024 units viscuts theres no rule about how big your brushes should be,little brushes just tend to make stupid little leafs when you keep them as world geometry (or tie them to func_detail if you need some).
Its just a matter of keeping your map clean and easy to modify.Working with standard units has to be taken as an advice but its not a rule...
If you need to place little details,use props,theyre way cheaper than brushes that uses lightmaps to render shadows and works far better with little objects.

ANY detail work should be tied to a func_detail brush, if you turn of details and your map doesnt look wolfenstein then you need more detail brushes (thanks ram)

Btw I had some testing yesterday and tried cutting a window sized nodraw face on a house (not carving it,just having a nodraw face at the surface of the house.

That nodraw face doesnt cut any more leaf but it allows to simulate a window thats carved into the wall without having a carved wall (I hope you see what Im trying to explain).

Originally posted by KominAaa
Btw I had some testing yesterday and tried cutting a window sized nodraw face on a house (not carving it,just having a nodraw face at the surface of the house.

That nodraw face doesnt cut any more leaf but it allows to simulate a window thats carved into the wall without having a carved wall (I hope you see what Im trying to explain).


So I just subdivide my large brush into chunks, and make a chunk textured with no draw, then slap the model on top of it, and it doesn't interfere - yeah that's good news - cheers!


Originally posted by tabu.jack
ANY detail work should be tied to a func_detail brush, if you turn of details and your map doesnt look wolfenstein then you need more detail brushes (thanks ram)

I need to investigate this - cheers for the hint

heres an easier way, simply lower gridsize to one lower the model into the wall until it starts to clip, if you need to push it in more then do the clipping work

And the next dumb question.

I'm messing around with the interior of a house.

I've got a stooopid problem: However many windows I put in my house, the interior is almost pitch-black. Now granted my skybox (hdr) is quite gloomy, so there's not a huge amount of ambient light, but playing the official maps, it's not nearly the same low level of light inside the buildings (regardless of absence of windows!).

I'm compiling with the full / slow options set, and I've tried buildcubemaps too.

So do the Valve maps have light entities inside the rooms to brighten them up? Or is my env_lightsource / env_sun / skybox gone screwy on me?

Any hints welcomed!

edit: I just remembered - my default brush type is 'func_detail'. Presumably my house and terrain are created with that, does that affect the lighting?

Sounds like you just need to fling a few light entities in there...

Originally posted by Brooker

edit: I just remembered - my default brush type is 'func_detail'. Presumably my house and terrain are created with that, does that affect the lighting?

Never ever tie a displacement into a func_detail.
It would break the entire internet and bring thousand years of darkness to all mankind by making the compilation crash.

Do not tie everything to details,just keep the backbone of your map as world,everything that needs make cuts on the leafs and "sectorize" the map.

Ok, open up the sdk_dod_flash map in your hammer, go to the visgroups section and take away details. This will allow you to see exactly the sort of thing that they are used for. Also the enviromental light, http://developer.valvesoftware.com/wiki/Sky_List that page gives the optimal setting for light enviroments, i suggest using these until you are comfortable with what the parts of the light_enviroment do, also the env_sun is not a light entity, it is only for decoration.

An interesting thing from the Flash vmf, Brooker, is the use of func_illusionary's. Open it up and see how they put a lot of those in doors and windows. They texture a brush with lights/white001.

Maybe a vet mapper can expound on this. I've found them to be too bright for my map (mine has a very overcast look).

I've tried experimenting with putting a light in certain places, without a lightbulb model attached. This is tricky, it can't be too bright or it looks odd (light from nowhere).

Maybe a vet mapper can expound on this also. I am ready to have my knuckles rapped by even FuzzDad, if necessary!!

Make a brush that is the same size as your window opening. Texture every face except the one that is facing the interior with nodraw. Texture the face facing the interior with lights/white001 (I believe that's the name).

Make the brush a func_illusionary, and change the render mode to "dont render".

Done. One thing I've noticed though, is that in Flash, the white texture is scaled to 1.25. I dont know what purpose this serves though.

Why does light in Source lose intensity when passing through a window or the like?

Thanks for all the hints guys, keep 'em coming!
I've not tried the window trick, but I will...

I've looked again at my maps, pretty much everything is a normal world brush. I'll have to start looking at what I can convert to func_detail (any suggestions?)


Originally posted by Dwin
Why does light in Source lose intensity when passing through a window or the like?

I guess it'd almost be a true ray-tracing program if it could do that - almost all the light coming through the windows in any map will have been reflected off something first.

Well, I got a bit too ambitious with my map - I'm building a big Normandy farmhouse, 3 floors, working fireplace etc etc. God it's hard work! Making a house with a truly realistic interior is damn hard - putting the stairs and bannisters in was quite a fiddle, and I've still not laid out all the rooms. And I've used dormer windows on the roof, but I'll need to replace them with brushes if I'm going to make the top floor accessible (they poke into the roof space)

It's all good fun though, and I might well release it on it's own in case anyone needs a big farmhouse for their map.

And when I've made the 'nice' version I'm going to try to make a partially destroyed one - that's what I need for the map I want to make...

You know, in one of those HL2 props folders, there's a really good looking attic window/dormer.

props_rooftop\attic_window.mdl

I wish I would've used it on my big dormer house, woulda saved me a lot of headache.

Originally posted by Ol' Noodle Head
You know, in one of those HL2 props folders, there's a really good looking attic window/dormer.

props_rooftop\attic_window.mdl

I wish I would've used it on my big dormer house, woulda saved me a lot of headache.


Ahhh, I just filtered by 'dormer', so didn't see it :rolleyes:

I wish the folders and names could be re-arranged. Could some clever VB / C++ programmer write some sort of alternative model viewer that transforms the data sorting so all the (for instance) doors sit in their own folder, regardless of which map they appear in, and what they're named? It would just need one table of meta-data to do, I reckon, and it would make life that much simpler!



edit: regarding those dormer windows.... don't use 'em (or use them with extreme care! I just spent ages replacing my roof so I could use them , then took a figurative step back and winced. They're bloody enormous. They're completely out of scale (to my eyes) with the rest of my house, which uses large broken windows (non shuttered) throughout :( Actually, I'll try using shuttered windows and see if that helps rebalance the appearance. But that'll mean basically starting again <sob>

Originally posted by Dwin
Make a brush that is the same size as your window opening. Texture every face except the one that is facing the interior with nodraw. Texture the face facing the interior with lights/white001 (I believe that's the name).

Make the brush a func_illusionary, and change the render mode to "dont render".

Done. One thing I've noticed though, is that in Flash, the white texture is scaled to 1.25. I dont know what purpose this serves though.

Why does light in Source lose intensity when passing through a window or the like?

I've done all that, and I've lit the inside of my building... but... it's too bright! How do I tone it down a bit? I've tried reducing render FX Amount from 255 to 50 and still the inside of my room looks like a nuclear flash is bleaching it....

thanks in advance ;)

Are you using HDR? In my opinion everything looks like a nuclear blast in HDR, I really dont like it :O!! *controversy*

Originally posted by otF yetihw
Are you using HDR? In my opinion everything looks like a nuclear blast in HDR, I really dont like it :O!! *controversy*

No, it's with HDR off*.

Well, I found I'd clicked on the wrong texture, I was using white 004. Changing it to white 001 toned down the effect quite a lot, but it's still too bright for the ambient light from my skybox, it still doesn't match up. I'll try some other textures tonight, but I'm sure there must be a way to fine-control it. Perhaps using the FX RGB value?



* For some reason when I run HDR my rooftiles are extra shiny - like they're coated in glass. Could be my Omega ATI drivers (with AI Enabled), or it could be the fact that the last time I ran in HDR mode my skybox wasn't sealed - I'd moved a boundary wall when selecting other stuff, it was basically missing, and yet the map still ran !?!

I like HDR - played with it 'on' last night but did get killed a couple of times because it distracted me. And DX8 mode with everything turned down adds 20fps to my average.

Oh dear, bumping my own thread ;)

The answer to my window question seemed to be to reset the textures to white 001, and to set the two 'shadow' properties to 'No'

And then I made sure my skybox was properly sealed.

It then seemed to magically work, and seems to do a good approximation of the light cast through the door / window, from the ambient light outside.

Huzzah!



Now I've got another problem: I've got lighting in my attic where there shouldn't be. I've converted all the roof brushes (and internal walls in the attic) to func_detail because they're not plain primitives anymore, and added in Light Block textured brushes lining the inside of the roof brushes. No joy.

What am I doing wrong?

It then seemed to magically work, and seems to do a good approximation of the light cast through the door / window, from the ambient light outside.
Thank you Brooker, I have got to try that.

Screenies please

Originally posted by tabu.jack
Screenies please

I've converted everything back to world brushes and still get the same thing :(

What should I capture in the screenies?

the light ing it the room, or just some genral screens of the room

Rather than post some screenies I think wouldn't really help too much, why not take a look at the real deal :)

The lighting problem is in the attic.

Compile times have really gone berserk since I worked on the roof - instead of 30 secs it's now 5 minutes. Now I know that's not very long for a map, but it's a big jump for the small extra amount of brushwork I did recently. So I guess I've introduced a problem some where. Portalflow takes a long time to run; do I need to area-portal my windows and doors? Or is it cos my roof and windows aren't func_detail yet?
Maybe I need to box my house in hint brushes so it's in just one leaf on it's own?

All hints gratefully accepted!

Try func_detailing and then compile. Works wonders! However, there are areas in my map that I'd like to areaportal...and they're surrounded by func_detailing...which is not good for areaportaling. Oh well!

Which leads me to MY Dumb nublet question of the day:

How do you UN-func_detail something? I need to change some brushwork, or try to use areaportals, and I overdid it on the func_details.

To unattach an entity from a brush use the "to world" butten next to "attach to entity" or use the ctrl+shift+w hot key.

Thank you very much, Grand Architect.

Brooker, rooves should be made into displacements

the columns on the front of the house look a bit too big and should also be func_details and the porch thing aswell. The shuttered wndows have alternative skins which make them appear as if light is comin through the slats. Ceiling beams should be detailed aswell as the wood shed and the step for the little house if you arent going to go inside the little building, i would make that detail aswell. Your light_enviroment doesnt have to be placed in the sky, just your env_sun has to. Apart from a few errors with the texturing alignment good work. I didnt want that to appear to be negative i just went round the map and wrote stuff down. As a first map its impressive as is your grasp of optimisation so early. *thumbs up*

Cheers Jack :D

The displacement roofs is one of those things I've got on my 'to do' list.

Along with func_detailing everything, once I can figure out what affects the lighting effects and what doesn't.

I still can't get the attic lighting sorted, even with everything as wolrd brushes :(

I'm going to try making a 3D skybox once hte house 'works'... that should be fun :)