Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351270 views, last view: 12/09/2021 04:21

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

   Board Index   

#1121: vcpp paths

by TOGoS_gbfewni on 09/16/2005 08:10

Visual Studio 2003 seems to accept ..\ instead of c:\w\sauerbraten\ for include and link paths (since the current directory is sauerbraten\vcpp). Assuming this is supported in other versions of visual studio, such a change would be appreciated.

reply to this message

#1122: Re: vcpp paths

by Aardappel_ on 09/16/2005 08:27, refers to #1121

just made all the paths inside the project file relative, long overdue, sorry.

The divide by zero bug was already fixed, believe it or not.

reply to this message

#1123: ..

by pushplay on 09/18/2005 07:30

Now that I've been getting some quality editing time done I've noticed a couple problems.

1. When positioned within a quad and selecting another quad the quad you're in gets selected even though you can't possibly see it so you must mean the next closest match.

2. Related to 1, if you think you've clicked on a quad and try to raise or lower it, but have actually selected something behind you, it will take several scrolls to realize what's going on. If you don't go back and look behind you for what you've damaged it could be a long time before you discover what changed. Depending upon the grid size this can be incredibly damaging. It might make sense to not allow edits that happen entirely behind the near clipping plane and echo a warning.

reply to this message

#1124: Re: ..

by Aardappel_ on 09/18/2005 09:04, refers to #1123

1. not sure what you mean here
2. I haven't had this situation, but yes that makes sense. Gilt?

reply to this message

#1125: Re: ..

by pushplay on 09/18/2005 21:30, refers to #1124

1. Time for another episode of everyone's favorite show: Variable Width Ascii Diagrams!

_______
|...........|
|...........|
|__A___|

__B____
|...........|
|....o.....|
|______|

Looking top down, you're at point o inside a quad looking at A, you can't see the structure that you're in so when you click you're looking at a face of A. But what gets selected is some face of B. What the user wants is to select A. This becomes a problem in tight spaces.

reply to this message

#1126: Re: ..

by Gilt on 09/19/2005 04:56, refers to #1123

1. by quad you mean cube right? when you are inside a cube, you can only select the cube you are in.. that's the issue, right?

I can certainly change that.. though not sure if that would affect lighting and other stuff and whether or not precautions should be taken to avoid that ..

2. should be doable I think.

reply to this message

#1127: terrain editing

by Gilt on 09/19/2005 05:10

not sure if I mentioned this before, but there is a command, editheight (key H), that you can all try out to make terrain. hold it down, and use the scroll wheel. it doesn't work with selections..

you'll probably need to dl default.cfg if you want to use it right now... or else just modify it yourself, works just like the R, T etc commands.

reply to this message

#1128: Re: ..

by pushplay on 09/19/2005 07:16, refers to #1126

Gilt: yeah.

Is cube the official terminology then? I wasn't sure, I think I've used both.

reply to this message

#1129: Re: terrain editing

by pushplay on 09/19/2005 07:30, refers to #1127

Basically it pushes a corner and the 3 adjacent corners, right? I created some illegal cubes really easily with it.

reply to this message

#1130: md3 animation blending

by >driAn<. on 09/21/2005 23:24

The code for md3 animation interpolation is commited to the cvs. If you have http://www.sprintf.org/sauerbraten/test-mdls.tar.bz2 installed, you can just replace the ogro path in fpsrender.h to use it.

Aardappel:

Could we take the occlusion culling out of rendermodel(..) and let every model type implement its own? The problem is, one instance of 'struct md3' covers multiple models (lower,upper,head), so it makes more sense to do a culling test on each (sub)model since each comes already with bounding box information. This would make things a lot easier.

If a dynent is rendered as md2 for some frames and suddently as md3, sauer might crash. To avoid this, dynent's animstate must be ::reset()'ed immediately after the switch, because every 'struct model' inheritance might interpret the animstate in a different way. Well, we could also implement some animstate checks in the rendering methods.

reply to this message

#1131: Re: md3 animation blending

by Aardappel_ on 09/22/2005 08:28, refers to #1130

good work... will have to try it later, in chicago atm.

We could take the occlusion out, but occlusion testing is not cheap, so I prefer it if you'd let that function return a bounding box for upper & lower together. But whatever is best in the end.

I don't see why one would ever want to have an animated character in a game constituting of some frames of md2, and then some in md3. So I'd rather not clutter the code with it. Unless you have a good reason.

reply to this message

#1132: Re: md3 animation blending

by drian@firm04 on 09/22/2005 10:25, refers to #1131

> So I'd rather not clutter the code with it. Unless you have a good reason.

It's only a problem if we support multiple playermodels the client can choose. So if somebody switches from a md3 model to the md2 ogro, sauer might crash. But yes, its not necessary atm.

reply to this message

#1133: Re: ..

by Gilt on 09/29/2005 04:45, refers to #1128

cube terminology: well, 'quad' I usually think of as just one of the faces of a cube.

anyway, can you test out how 1) and 2) feel like now? same with the editheight command (yeah, it just pushes all four corners).

reply to this message

#1134: Re: ..

by pushplay on 09/29/2005 05:17, refers to #1133

Quads make up a cube, sure.

2) was bang-on. Thanks. 1) is great except for 2 problems. It looks like the calculation for "behind" is based upon the center of the selected volume but should probably be the most inclusive corner. Also, it shouldn't apply to dealing with entities.

The editheight command is nice btw.

reply to this message

#1135: Lighting

by pushplay on 09/29/2005 05:47

Quake3 shaders had a couple of features which would make attractive lighting easier.
q3map_sun: http://www.heppler.com/shader/shader/section4.htm#4.4
q3map_surfaceLight: http://www.heppler.com/shader/shader/section4.htm#4.5

By applying the surfacelight only to the skybox texture and setting the values intelligently you get nice hard shadows cast by details and a brighter outdoors than indoors. Basically it gives you a nice base to work from. I'm trying to emulate the effect by hand and it's not trivial.

A sun command would probably have to be split up into sunintensity and sundirection because of the 6 args.

reply to this message

#1136: adding to that..

by tentus on 09/29/2005 07:12

well, in theory, you could just make the entity position cover the degrees and elevation. that'd be in keeping with the current scheme of things. of course, if you wanted to be real slick (and mapper friendly), you could make it so the entity is generated right inside the skybox, wherever the mouse is pointed. this'd save mappers from having to fly around for several minutes to get a very simple task accomplished. gamespeed helps, but still, flying up to a corner, down again, and deciding to stick your "sun" in a slightly different place is just not fun.

while we're on lighting, has any more though been put into 'groundlight' or such entities? i'm thinking of lights that only affect surfaces facing upwards up to 45 degrees. basically, the current cube lights minus the walls and ceiling. this could really improve performance, because in my expirience more than half the lighting is focused on the floor, with much less being on the walls, and then very little on the ceiling. by being able to break down the lighting a lot of unnescessary lightmaps could be avoided. it might even be possible for groundlights to be rendered dynamically, because they'd be even simpler than the current Cube lights.

reply to this message

#1137: ogz?

by tentus on 10/02/2005 20:26

this feels like a dumb question, but what does ogz stand for? i know that cgz is short for cube.gz, so i'm assuming that ogz comes from octree.gz or something, but i've always wondered.

reply to this message

#1138: Re: ogz?

by Aardappel_ on 10/02/2005 23:15, refers to #1137

yup... .OctaGnuZipped

reply to this message

#1139: ..

by pushplay on 10/03/2005 05:28

No comments on the lighting idea?

Anyways. I presumptuously threw a beta of my map 'yesterday' in cvs. Should look familiar. The pickups will need tweaking, the lighting is temp, and it obviously needs to be clipped. Clipping this is impossible until it can be rendered.

Feedback is nice. Positive feedback is great. :)

reply to this message

#1140: Re: ..

by Aardappel_ on 10/03/2005 07:41, refers to #1139

from you description I have no idea what the q3 system does that we don't already have.

reply to this message

   Board Index