Sauerbraten engine development

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

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

   Board Index   

#1028: occlusion culling

by schraf on 07/28/2005 03:29

The discussion got me interested in occlusion culling algorithms. Thought I would throw out some good reads for those that might not be very familiar with the pros and cons for the various algorithms:

http://graphics.lcs.mit.edu/~fredo/PUBLI/surveyTVCG.pdf

http://people.csail.mit.edu/seth/pubs/pubs.html

reply to this message

#1029: Re: occulsion cullling

by schraf on 07/28/2005 15:14

Now that I go back, I had thought there were more papers on occulsion. But here are some that stand out on that page (i think most of them show an approach that requires an off-line portion, but the previous works are nice):

Real-Time Occlusion Culling for Models with Large Occluders

similarly

A Spatially and Temporally Coherent Object Space Visibility Algorithm

also

Visibility Computations in Densely Occluded Polyhedral Environments

and

Visibility Computations in Polyhedral Environments

and

Visibility Preprocessing for Interactive Walkthroughs

reply to this message

#1030: rpgish

by staffy_051 on 07/29/2005 11:51

http://cube.snieb.com/node/110

reply to this message

#1031: ..

by staffy_051 on 07/29/2005 12:13

just ignore it. It is just to remind you to get the latest sauerbraten.exe. (without it the map will be unplayable)

reply to this message

#1032: ..

by staffy_051 on 07/29/2005 12:24

http://cvs.sourceforge.net/viewcvs.py/sauerbraten/sauerbraten/sauerbraten/bin/sauerbraten.exe?rev=1.86&view=log

reply to this message

#1033: Re: CVS

by rootnis on 07/29/2005 21:17, refers to #1033

it is already in sauer for more than two weeks

reply to this message

#1034: ..

by shahar2k on 07/31/2005 08:54

random question, uhm the maps in sauer dont really occupy that much memory space as far as I know... what's stopping people from "linking" multiple maps together, and loading the next nearest map as you get close to it (say a portal type trigger) so that the transition from one map file to the next is seamless

reply to this message

#1035: ..

by _tester on 07/31/2005 09:27

u must not know what yur talking about

reply to this message

#1036: Re: ..

by staffy_12 on 07/31/2005 09:46, refers to #1034

1. There isn't much of a need for map linking at present (as far as I know).
2. It requires coding (and could be a large amount of work)

other than that it could be done.

reply to this message

#1037: Re: ..

by Gilt on 07/31/2005 18:44, refers to #1034

if two areas are meant to be connected, why not just put them in the same map?

reply to this message

#1038: Re: ..

by TOGoS_1u2kuhbui on 08/01/2005 05:36, refers to #1037

> if two areas are meant to be connected, why not just put them in the same map?

Because you might end up with infinitely large maps that way.

Not that this is a problem at the moment, but someday... ;)

reply to this message

#1039: ..

by clans on 08/02/2005 01:20

i like the idea of one map than a whole bunch of maps linked together

by shahar2k on 07/31/2005 08:54 through
71.133.216.49
>>uhm the maps in sauer dont really occupy that much memory space as far as I know... what's stopping people from "linking" multiple maps together

well just like you said, map files are already small.. why link when u can have 1 map. But i guess linking larger maps together would have a point to it.

but for now, id say no to linking them.

reply to this message

#1040: skin sharing

by Aardappel_ on 08/02/2005 06:56

multiple models can now share the same skin, to save space, by simply putting the skin in the parent directory. So for a

mapmodel "x/y"

the search order is now:

"x/y/skin.jpg"
"x/y/skin.png"
"x/skin.jpg"
"x/skin.png"

reply to this message

#1041: texture rotation

by Aardappel_ on 08/02/2005 08:08

the new "texture" command can now save you from needing to have multiple rotated copies of a texture on disk:

texture subnum filename flags

Binds the texture indicated in filename to the current texture slot, then increments the slot number. This is for use in texture.cfg files only. subnum allows secondary textures to be specified for a single texture slot, for use in shaders and other features (unused for now, should be set to 0 to indicate primary texture). Flags allow you to specify preprocessing on the image, currently only rotation (0 = none, 1 = 90 CW, 2 = 180, 3 = 270 CW).

If anyone wonders why I don't simply rotate the texture coordinates, that is because there currently are no texture coordinates in the vertex stream (adding them would add 40% to the vertex bandwidth). If there should be in the future, I can transparently replace this texture memory heavy solution.

reply to this message

#1042: Re: texture rotation

by TOGoS_1u2kuhbui on 08/02/2005 16:48, refers to #1041

Woohoo! Thanks aard. That'll be very helpful.

Also thanks to whoever put the 'ambient' variable in.

reply to this message

#1043: ..

by shahar2k on 08/02/2005 19:51

..

reply to this message

#1044: ..

by shahar2k on 08/02/2005 19:58

pressed the submit button a bit early...

map linking is something I suppose only specific games really need, you could do without it by creating a bit of overlap between maps (modeling part of map a inside map b and then putting a go to map trigger so the player dosnt notice he's been transferred into the next map)

this is useful for RPGs that use continuous worlds, or a game like Half life where the action should not be interrupted. either way just wanted to say that saur at the moment looks great, especially the proffesional looking maps being made for it. Now all it needs is better looking models (the pistol model is a start)

if somone would like to draw up some concepts, I'd be happy to model some things for sauer to use, weapons, mosnters whatever... maybe even animate, provided I do it before my school begins again on the 29th...

reply to this message

#1045: Lighting

by tentus on 08/03/2005 16:21

So far Sauer is confined to spherical lighting, which takes time to compute, yes? Cube used Cylindrical lioghting, which takes vastly less time to compute, yes?

Would it make sense to add in another way of lighting to Sauer to augment the current system? I'm suggesting that another kind of light entity "f_light" be made, short for "floor light". Have circular lighting *on the ground only*, to add to the spherical lighting. This would take even less time to compute than the cube lighting, because it would not affect walls or ceilings, which would speed up rendering. I've found that when I'm lighting my levels i spend far more time and energy lighting the floor than anything else, and as such i think that only the exclusively-floor lighting would be nescessary, not ceiling or wall lighting too.

This could even be tweaked so that f_light is rendered upon the level load, unlike the spherical lights, which would save on map filesize and not significantly detract from loading time.


Any comments on this idea? Engine bloat perhaps, or too much conflict with spherical lighting?

reply to this message

#1046: Re: Lighting

by Pxtl on 08/03/2005 18:07, refers to #1045

Don't think the optimisation would help. Cylindrical lighting worked in Cube because Cube's grid was fixed and regular. Sauer's octree is irregular (you can push the nodes around) so overhangs and angles would make cylindrical lighting hard.

What would be more appropriate (but much harder for mappers to find useful) would be to allow each sauer cube to define an ambient lighting level and multiple rectilinear light flows within the field. These settings would be propagated down to smaller cubes, to be supplemented or overridden at that level.

Now, this scheme is obviously painfully complicated, but really, it's the only way I see that you could have a "simplified" lighting model available as an alternative to traditional point and field sources in Sauer (besides the occaisional fully-dynamic light).

To me, the most sensible approach would be to have a quick-and-dirty set of lights that can be used during edit-time and can easily be implicitly swapped out with the fully resolvable lights.

reply to this message

#1047: Re: Lighting

by tentus on 08/03/2005 19:11, refers to #1046

i'm not suggesting cylindrical lighting- it's 3D. I'm suggesting that Sauer use circular lighting (hence 2D) on faces that were originally horizontal and facing up. Sorry if i wasn't clear on that- the Sauer engine should have an easy time identifying what faces are relevant to this supplemental lighting scheme.

reply to this message

   Board Index