Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351346 views, last view: 12/09/2021 06:35

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

   Board Index   

#1141: Re: ..

by pushplay on 10/03/2005 08:11, refers to #1140

In the sense that we already have a command for that or that you think the effects can be done manually?

reply to this message

#1142: Re: ..

by Aardappel_ on 10/03/2005 11:14, refers to #1141

in the sense that I do not understand what effects you are talking about at all :)

reply to this message

#1143: Re: ..

by pushplay on 10/04/2005 02:16, refers to #1142

Oh, ok.

Well sun is pretty straight forward. All skybox textured faces cast a ray of the defined angle and intensity of the sun, with no falloff, giving the effect of the sun shining down on the map. You can't do that with light entities.

With surfacelight the skybox textured faces cast an omni-directional glow with (configurable?) falloff, like the light scattered by the atmosphere. You can emulate that with light entities if you're good but it's still a lot of work.

reply to this message

#1144: Re: ..

by Aardappel_ on 10/04/2005 03:55, refers to #1143

we already have a no-falloff light, and if you place it far away it is close enough to unidirectional.

An omni directional skybox light could certainly be very cool, but I see no cheap way to implement that at this point.

reply to this message

#1145: Re: ..

by shadow.516. on 10/04/2005 14:35, refers to #1144

>we already have a no-falloff light, and if you place it far away it is close enough to unidirectional.

Except that it is time consuming to place correctly (let alone adjust), and takes way too many resources to calclight an omni-directional sun (especially on lower lightprecision). The time saved by using a uni-directional sun well makes up for the engine bloat.

reply to this message

#1146: Re: ..

by Aardappel_ on 10/04/2005 20:14, refers to #1145

uh? it would not be any cheaper to compute a unidirectional light.

reply to this message

#1147: ..

by Xsaii on 10/05/2005 04:45

How about inserting "/me" commands possibly? I just took a look at that MMORPG and thought about those ridiculously huge maps in the new version of saur.

If the servers had enough players there could basically be roleplaying, intended noone is DMing.

reply to this message

#1148: Re: ..

by makkE on 10/05/2005 12:05, refers to #1147

In case by "that mmorpg" you meant the "rpg (wip)" folder in sauer, you might have noticed the WIP in there.
Those are not meant for dming.

Plus, this thread is called "sauerbraten engine developement", not "Sauerbraten MMORPG beta v1.0 feedback"

Asking for a /me comand at this stage is like asking to put a picture on a wall in a house you build when the first wall is just up..

Maybe this might clarify:
http://www.cubeengine.com/forum.php4?action=display_thread&thread_id=596

reply to this message

#1149: ..

by Xsaii on 10/06/2005 05:23

I can't seem to find any RPG folder, I must not be looking hard enough.

If you ment the huge rpg maps, yes, that's what I ment. As I said that no one is INTENTIONALLY dming.

After re-thinking my idea, it seems I forgot Saur's key quality is supposed to be based on simplicity, therfore, adding a suggested idea like mine, would be no use.

Hrm, I couldn't find a thread for Saur ideas so I decided to put it here, instead of making a randomly useless thread with just a single idea in it.

reply to this message

#1150: Re: ..

by pushplay on 10/06/2005 07:43, refers to #1144

I'll keep relighting yesterday until I find something that works for me. There's something inherently unsatisfying about trippling the volume of space the map occupies to place a single light though. code complexity v. map complexity I guess.

reply to this message

#1151: Lighting during Editing

by spentron on 10/07/2005 04:18, refers to #1150

I still see lighting during editing the biggest weakness of Sauer relative to Cube. A fullbright world is not very 3D and makes it difficult to work in. Either some kind of simplified lighting is needed for edit mode or altered cubes need to be lit bright enough to see properly.

Please do something.

reply to this message

#1152: LOD

by Aardappel_ on 10/17/2005 22:53

A little warning for those who like to play around with fresh CVS versions, I am implementing LOD (level of detail) for the larger maps, and this is going to take many smaller refinements, meaning that it is working but not looking good just yet. So don't report "bugs" unless it is not mentioned in the TODO text :)

The good news of course is that soon we will be able to run the RPG maps at a fraction of the original geometry load, with little or no visual difference. It already is a hell of a lot faster right now (see history.html).

reply to this message

#1153: mmm, fresh tasting CVS

by tentus on 10/18/2005 05:50

is the mapper going to be able to mess with this in the map itself? sometimes it'd be best if mappers could manually define an area not to LOD, because the geometry breaks down. i trust that this won't be a serious problem for a good while, but it'd be good to have that already in place, while LOD is being developed.

reply to this message

#1154: Re: mmm, fresh tasting CVS

by Aardappel_ on 10/18/2005 12:52, refers to #1153

you can turn LOD on or off for a map (default off). No, you can't influence it. It is up to the player to tweak visual quality vs speed on large maps that have LOD turned on.

reply to this message

#1155: About lighting

by mystic_mage on 10/25/2005 00:11

since the guy up above was talking about quake3 lighting. How about looking into HDR lighting. Gamedev has a few examples to play with.

http://www.gamedev.net/community/forums/topic.asp?topic_id=345577

reply to this message

#1156: Re: About lighting

by mystic_mage on 10/25/2005 00:20, refers to #1155

another example of HDR.

http://www.gamedev.net/columns/hardcore/hdrrendering/

reply to this message

#1157: Re: About lighting

by Aardappel_ on 10/26/2005 03:10, refers to #1157

HDR is a generic term, and can be done in the same fashion in either OpenGL or D3D.

reply to this message

#1158: entity snap

by Sparr on 10/26/2005 10:43

a small snippet of code that snaps the nearest entity to the cube grid (at the current gridsize). this functionality may already exist as part of something like dropent, but I couldn't puzzle out how to use it if it does.

void entsnap(void)
{
if(noedit()) return;
int e = closestent();
if(e<0) return;
entity *nearest = et->getents()[e];
loopi(3) nearest->o[i] = gridsize*((((int)nearest->o[i])+gridsize/2)/gridsize);
}

COMMAND(entsnap, ARG_NONE);

reply to this message

#1159: ..

by makkE on 10/26/2005 14:15

Yes dropent does just that, only thing is you have to select yout "target" corner first, and entdrop must be either 1 or 2.

So you hover near the ent, choose a corner and do /dropent.

reply to this message

#1160: ..

by makkE on 10/26/2005 16:01

/entdrop 2 does it too, and makes it feel just like in cube. Dunno why any extra code should be written.

reply to this message

   Board Index