Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1689931 views, last view: 04/19/2024 16:29

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

   Board Index   

#941: ..

by TOGoS_1u2kuhbui on 07/03/2005 01:16

There seems to be ambient light already (even the darkest shadow is not totally black), it's just not adjustable. I'd be surprised if the option wasn't put in sooner or later.

reply to this message

#942: Re: ambient lighting

by Aardappel_ on 07/03/2005 16:43, refers to #940

yes there is already ambient light, fixed at about 10%

for those of you who think shadows are all black: you either have a very crappy monitor or have weird settings (like super high contrast).

The reason is fixed because 99% of the time people want to raise it, it is for the wrong reasons. Repeat after me: GOOD LIGHTING SHOWS CONTRAST. Not every polygon needs to be touched entirely by light. Shadows are good (if people hiding in the dark is a problem gameplay wise, we will solve that otherwise... they already show up less dark).

Learn to light levels properly. Start with the biggest, most prominent lights first and continue on down as required. For many levels that means the correct placement of a sunlight (newent light 0 255 200 100) somewhere high up.

reply to this message

#943: new models

by da-mitaman on 07/03/2005 17:34

It would be nice if the next release of sauer included all of DCP's map models. He has some wonderful stuff and it would'nt take up much space.

I also got hold of the newest textures (from cvs)for sauer. Nice selection, however i notice that some of them are far too "overbright" and need to be darkend up a bit. Some of the textures are hard to see (too bright) when editing with "fullbright 1" enabled.

reply to this message

#944: Portal / occlusion algorithm

by Aardappel_ on 07/03/2005 17:50

details here: http://strlen.com/wiki/?id=SauerPortals

(also in this context note http://strlen.com/wiki/?id=SauerWikiUsage)

reply to this message

#945: Re: ambient lighting

by Gilt on 07/03/2005 18:14, refers to #942

This is simply not true. For example an old quake map of mine, Ruby Midnight, received critical praise for its lighting, which featured prominent use of ambient lighting. The beautiful mixing of colours that ambient lighting creates, produces a sublimely diluted and washed-out look that everyone loves.

reply to this message

#946: heighfields in sauerbraten

by Aardappel_ on 07/03/2005 18:16

http://strlen.com/wiki/?id=SauerHeightfield

reply to this message

#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

   Board Index