Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1692821 views, last view: 04/29/2024 01:17

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#947: Re: ambient lighting

by Aardappel_ on 07/03/2005 18:17, refers to #945

I am not saying that it is not possible, just that almost everyone uses it wrong.

reply to this message

#948: Re: ambient lighting

by Gilt on 07/03/2005 18:24, refers to #947

ahaha.. just joking. the lighting in that map got panned so badly that I'm still mentally scarred to this day...

reply to this message

#949: Re: ambient lighting

by Gilt on 07/03/2005 19:21, refers to #948

seriously though, when it comes to stuff like ambient lighting or smaller gridsizes... yes there is the possibility of it being used well, but the much more likely scenario is that it will be horribly abused and ruin your map.

I'm reminded of the carving feature in quake editors. Who thought that that was a good idea to put that 'feature' in? They may as well of just included a giant button that you can click on to corrupt all the brushes in the map. It's like some kind of sweetly terrible newb-trap. What kind of sadistic designer does that?

smaller gridsizes especially, will be even worse since mappers seem to be attracted to it like moths to light.. come on, can't you see the ELECTRIC ZAPPER!?! I'd only be comfortable putting that in when people stop wanting it.

reply to this message

#950: Re: ambient lighting

by Aardappel_ on 07/03/2005 19:54, refers to #949

Agreed. There's always that central question to any kind of "design" to what extend you just need to enable users to do anything, or wether the designers god-like wisdom is allowed to restrict users to protect them against themselves.

I am aware that it can go wrong, but I am in favor of doing it anyway. The biggest reason is that the highest quality designs are about making good choices. Trying to make everything as "flexible" as possible gets you very generic things which are not good at anything in particular. Flexibility also has a high cost, in bloat and different possibilities to maintain.

Even better, for projects which I don't earn money on, I can afford to let "good design choices" overrule "customer demand" :)

reply to this message

#951: ..

by TOGoS_1u2kuhbui on 07/04/2005 01:21

Well can we have ambient light be at 0 instead of 10% then? You can always make things brighter with lights. Darker not so.

reply to this message

#952: Re: ambient lighting

by enigma_0Z on 07/04/2005 01:51, refers to #950

I don't know, probably the mapping noobs will use ambient light alot, but not the experienced mappers...

My main problem is this:

For outdoor maps, there needs to be some ambient light, otherwise the shadows are too dark. Doing an outdoor map with alot of buildings, there are notibly dark shadows... really dark shadows. Now that's nice for contrast etc. but bad when you are trying to make it look like a bright day.

I dunno, if it were adjustable I would be happy... for nighttime and indoor scenes it's pretty good, for daytime outdoor stuff not so much.

reply to this message

#953: ..

by TOGoS_1u2kuhbui on 07/04/2005 03:00

For dark cave scenes it ain't good, either. I'm of the opinion that not including such a simple and useful feature just because some people might abuse it is silly. If they abuse it, don't play their maps. And put a big "YOUR MAPS WILL LOOK CRAPPY IF YOU OVERUSE THIS FEATURE" sticker next to it in the docs. :)

reply to this message

#954: ..

by TOGoS_1u2kuhbui on 07/04/2005 03:15

On the subject of lighting, I've been thinking that a useful lighting mode (a la 'fullbright', but different) for editing would be to light faces based soely on angle. It would give a much better hint as to the geometry of whatever you're editing without having to recalclight all the time.

reply to this message

#955: Re: ambient lighting

by tentus on 07/04/2005 04:41, refers to #942

why not fix the default ambient light at 15% and give the mapper 15% leeway? if they want 0% ambient light they could have it, and if they want 30% they could, but incompetents wouldn't really be able to abuse it because they'd have to use real lights to get anything properly lit.

reply to this message

#956: ..

by pushplay on 07/04/2005 05:55

What happened to Sauer's physics? The controls feel real loose and sloppy now. Also, when you bunny hop you get extra height on all jumps after the first and can jump one cube higher.

reply to this message

#957: Re: ..

by enigma_0Z on 07/04/2005 06:04, refers to #956

I already posted the bouncy jump affect in the sauer bug reports thread. thx.

reply to this message

#958: New Commands

by pushplay on 07/04/2005 06:13

At this point if anyone creates any new commands they should be added to the document. It's a helluva lot easier for you to add them yourself than for me to hunt it down. The format is all nice and clean now and easy to edit.

Fullscreen and screenres are two commands where I can't see if they actually do anything or not.

reply to this message

#959: Re: ..

by Wolf on 07/04/2005 06:39, refers to #956

i believe that the different controls happened because eiruhl or w/e changed the physics code slightly. im trying to track down a previous version to recompile and see if this is it. just a guess on my part at this point.

reply to this message

#960: Re: ambient lighting

by Gilt on 07/05/2005 00:58, refers to #960

Let's put it this way, do you believe that all programming languages should include the GOTO statement?

reply to this message

#961: ..

by TOGoS_1u2kuhbui on 07/05/2005 01:11

Once in a while, goto comes in very handy. I tend to miss it when it's not there (or is restricted like in C# and can't jump 'into' blocks. Think elseif chains.)

Anyway, adjustable ambient light is a lot more useful (necessary, I'd say) than goto. Especially if I DON'T WANT AMBIENT LIGHT BUT IT'S STUCK AT 10%. Maybe you should remove the ability to carve out cubes because some people will make really stupid maps with it.

reply to this message

#962: Re: ambient lighting

by enigma_0Z on 07/05/2005 06:10, refers to #960

Well goto is pretty much useless if you structure your code right... I haven't needed it since my BASIC days.

but IMO this has no bearing on sauer's lighting... it is unrealistic to brighten up shadows with little dots of light when it's reasonable that ambient reflected from other surfaces adds light.

reply to this message

#963: Here's a thought....

by Pxtl on 07/08/2005 02:16

How about a global scaling of the lightmap available from script? That is, apply the lightmap at 10% or 50%? I only suggest this because I'm a big fan of the Darkmatch modes in UT (similar to the flashlight/weapons gameplay of Doom 3, but not as stupid) and it would be nice that, if post-map scripting for mutators/mods were possible, that a darkmatch mode would be possible for Sauer.

reply to this message

#964: Another idea...

by enigma_0Z on 07/08/2005 17:25

I had thought of this a long while ago, but your post, pxtl, reminded me of it.

Could we save multiple lightmaps with a level? Or at least partial lightmaps? If you could then add lightmap-switching and saving commands, you could have triggers that turn room lights on and off, as well as several other cool things. (Including Pxtl's "darkmatch" idea).

reply to this message

#965: ..

by Aardappel_ on 07/11/2005 10:12

there's a preliminary 3rd person perspective mode. switch it on using the "thirdperson" variable.

The evils of glReadPixels() have been removed from the code. That means no more people asking why rockets explode in their face.

reply to this message

#966: Re: ..

by enigma_0Z on 07/11/2005 18:19, refers to #965

Very cool... very cool!

If third person mode is going to become permanent, will we get vwep support so we can see the weapons our character and the other characters/monsters are holding?

reply to this message

   Board Index