Sauerbraten engine development

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

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

   Board Index   

#1098: General Water Inquiries

by Steve on 09/10/2005 22:52

First off, I\'d like to write that I\'ve enjoyed learning rudimentary map editting in Sauerbraten. It has been a fairly fun experience & I look forward to learning even more. With that written, I do have some observations that I would like to state :

1). Water implementation seems to be harder then it should be. Although I have had no problem making an initial flat-bottom pool, any attempts to make that pool\'s bottom uneven has resulted in pockets of air forming at the bottom. A combination of pushing / pulling cubes along with changing materals before & after said pushing or pulling has not given me consistent results. I am mystified at this & can not find a solution.

2). Will there eventually be a method for producing currents in water?

3). Currently, it seems that the water is designed only to be in a pool environment. Will it eventually be designed for situations like waterfalls or flowing out of pipes?

If these questions have already been answered previously, my apologies. I have only recently begun reading the threads in these forums. Thank you.

reply to this message

#1099: MD3 for Sauerbraten

by >driAn<. on 09/10/2005 23:29

http://sprintf.org/sauerbraten/md3.jpg

I coded md3 support for sauerbraten. Atm there is only one player- and weapon model slot since I don't know how the engine should interface with the md3 code: access using a hashtable (as in md2) or via id's.
The md3 code has a very good functionality/size ratio (IMHO) since it provides custom skins per mesh, custom anim. frames, linking, etc as in Q3A in less than 400 code lines. Sure, those customizations could be hardcoded, but actually all the models on the net require it.
If we stick with md3 in the future and make models for it, we could now discuss how exactly it should be accessible, what features it should provide, etc.

(human-readable) diff to the cvs
http://sprintf.org/sauerbraten/md3.diff

To test it, get this model package and extract it to the game-root
http://sprintf.org/sauerbraten/test-mdls.tar.bz2

/loadplayermdl lobo
/loadweapons
/weapon 0
/thirdperson 1

Again, the storage & access of the models is a hack atm.

reply to this message

#1100: Re: MD3 for Sauerbraten

by >driAn<. on 09/10/2005 23:37, refers to #1099

So, post your feedback and tell me if it fits the philosophy ;)

reply to this message

#1101: ..

by >driAn<. on 09/11/2005 00:52

..thats up to the main dev's. It's not that tragical if they don't accept it, it was fun to code it :)

reply to this message

#1102: ..

by -Rick- on 09/11/2005 01:23

Nice job :)
A good and better looking model format was something which sauer was missing :)

reply to this message

#1103: Re: MD3 for Sauerbraten

by Aardappel_ on 09/11/2005 02:09, refers to #1099

looks pretty good. There's a few things which I want to do differently, but this looks like a good base to start from.

We'll integrate it, and I will put some code in to make the whole model rendering thing a bit more format independent. I am also preparing to have a 3rd custom format for sauer, so it should all be a bit more generic. Supporting 3 model formats sounds like bloat, but all 3 model formats are compact and have their uses... who knows if in the future we don't have any md2 art anymore we can ditch it :)

If you want to keep improving on it, I can probably give you cvs access, and we can talk about what to improve.

Is the code 100% yours, or is there a base of an existing loader in there?

reply to this message

#1104: Sauerbraten campaign....

by Invincible_777 on 09/11/2005 02:44

This is my first post on this forum. I never really liked cube much. I always thought the monsters sucked. And I realize now that the res sucked. Now, with Sauerbraten, I can get 1240x1024 resolution. I forced myself to learn how to use the editor. I know have about 4 maps, which I plan to merge into one large world. I am wondering if anyone has tried this? I would love to get a hold of any new mapmodels and/or monsters etc. But what I really want most is characters/entities that dont attack you (i.e. a bartender/store keeper). If anyone would like to test my map set/campaign, please email me and let me - tell me what I need to give you for you to test it, and then let me know what you think! Thanks

reply to this message

#1105: Re: General Water Inquiries

by Gilt on 09/11/2005 03:50, refers to #1098

Steve:

1: you need to make sure that the cubes at the bottom of the pool are also set to water. you should be able to just select the cubes where the air pockets are, and change them to water.

2: yes, currents or just general pushes will most likely be added.

3: I'm sure there will be models or stuff that will be added to give the appearance of a water fall. but I don't think we'll need the cubes to be "actual water", as you can't really 'swim' in a water fall : )

reply to this message

#1106: conversions

by staffy_27 on 09/11/2005 05:57

I made a quick conversion of douze: http://cube.snieb.com/node/129

reply to this message

#1107: Re: MD3 for Sauerbraten

by Aardappel_ on 09/11/2005 05:59, refers to #1099

ok, I factored out all the md2 frame stuff out of the game code into the md2 loader, and made all the model loading/rendering stuff generic. All that remains is a little bit of integration, drian, have a look at the md3 class in md3.h, and talk to me if you have any questions.

reply to this message

#1108: Re: conversions

by makkE on 09/11/2005 12:36, refers to #1106

Staffy why do you think you can go ahead and mess my map up?!
It´s not like I vanished from the scene for 2 years or so. You should have asked me before :S :S

I´m working on a douze port myself, would you please erase your silly 30mins version? thank you.

reply to this message

#1109: Re: MD3 for Sauerbraten

by >driAn<. on 09/11/2005 13:16, refers to #1103

Thanks for the positive feedback =)

"If you want to keep improving on it, I can probably give you cvs access, and we can talk about what to improve."

Yes, I would like to continue improving it. If you want me as dev member, my sf.net id: adrian_henke at users.sourceforge.net

"Is the code 100% yours, or is there a base of an existing loader in there?"

At the beginning I used gametutorial's code and other doc's to study how exactly md3 works, this code was bloated and not OSS. So, after I learned enough about md3 I rewrote it completely from scratch.

"All that remains is a little bit of integration, drian, have a look at the md3 class in md3.h, and talk to me if you have any questions."

Ok, thanks :)

reply to this message

#1110: Re: conversions

by MitaMAN in the cave on 09/11/2005 14:33, refers to #1108

As far as converting CUBE maps to SAUER I think that everyone should ask permission from the map creator first (if the creator has no plans to convert them themselves).

Here's a good question, are maps considered "public domain", so anyone can do what they want with them?

In all of my maps readme files I state: "You MAY NOT use this level as a base to build additional levels." I doubt anyone will convert any of my SP maps, but I hope any that wanted to would ask permission first.

I may convert a few of my maps once triggered doors are implemented in SAUER and an in-process project is completed (if anyone cares).

MitaMAN

reply to this message

#1111: Re: conversions

by >driAn<. on 09/11/2005 15:30, refers to #1111

Releasing software as open source is a good thing, releasing maps under likewise terms is good too, imho.
A webpage with such a listing is not necessary, just read the readme that comes with each map.

reply to this message

#1112: Re: conversions

by Aardappel_ on 09/11/2005 23:09, refers to #1110

don't worry, I am only going to accept converted cube maps into sauer that are

a) done by the original author
b) were among the best cube maps to start with
c) are a very good conversion, meaning that they have excellent lighting, fixed entities where necessary, and fixed arches and such.

That said, I encourage people to make some kick ass conversions of the better cube maps. You should wait until you get an exe of yesterdays dev cvs at least though, since I fixed a problem with entities and gilt improved remip which makes converted maps a LOT smaller.

reply to this message

#1113: Re: MD3 for Sauerbraten

by Aardappel_ on 09/11/2005 23:24, refers to #1109

excellent. You are added to the dev cvs.

As I said, please continue the integration I have started by means of the md3 class.

Other things I see you could do:

- you do not require data in dynent until you implement animation blending. So either just remove it there and keep it local in the render function, or use the same animstate struct that is already there.

- if you want people to be able to use md3's for mapmodels, items and such, you should implement VBO's for ANIM_STATIC (look at the md2 renderer and see how its done).

- generally, you want to have a good look at the md2 class, and see if there's any functionality of it you are not supporting. The more similar they are, the more people can choose between dm2 and md3 arbitrarily for any use

- minor issue: not all your code formatting corresponds to the rest of the sauerbraten code. Consistency above everything.

- we'll have to figure out the vwep thing later.. maybe if we switch to mostly md3s for players/monsters we can just ignore that md2's don't have any. We'll need 3rd person versions of the actual cube weapons?

In general, from your code it seems like you have taken the sauer coding philosophy to heart, though there's still room for improvement. As always, fixes, making things more robust, and refactoring for better code quality are more important when you work on sauer code than new features. Please do this as much as you can. New features, unless they are dead obvious and a very high functionality : code size ratio, should be discussed here first before implemented, especially if they affect the infrastructure of the engine (i.e. stuff in the "shared" part. Features which are confined to a module are less problematic.

I guess once drian has integrated stuff, we can look at the best md3 models that are worth integrating. If you go browsing on polycount, 2 things are important:
- the author readme states that it is free for non-commercial use somehow
- the model stays within a theme. I would like to keep the main FPS game more about monsters (as the current selection of md2s), less about realism. So any models that are scifi, realistic humans, or characters from existing games/cartoons/whatever, are not applicable.

One model that I really like that I have already seen is of a dragon... I think its one of the highest rating ones in there.

reply to this message

#1114: Re: MD3 for Sauerbraten

by Aardappel_ on 09/11/2005 23:35, refers to #1113

oh and I forgot, of course md3's need animation blending too. If not, animated md3's will actually look worse than md2 whens switching between animations. Check the md2 class how its done.

reply to this message

#1115: Re: MD3 for Sauerbraten

by drian_school02 on 09/13/2005 12:31, refers to #1114

Ok, I will look at those.

"- you do not require data in dynent until you implement animation blending. So either just remove it there and keep it local in the render function, or use the same animstate struct that is already there."

Ok, but I need to add 'int anim' to the animstate struct because md3 animations can share their frames, I need to know which BOTH_/LEGS_/TORSO_ is currently active. This will make things a lot easier.

reply to this message

#1116: Re: MD3 for Sauerbraten

by Aardappel_ on 09/13/2005 20:29, refers to #1115

that's fine.

reply to this message

#1117: Mirror

by pushplay on 09/14/2005 05:13

Is there no mirror command yet or did I miss it? I was working on my map and started hitting M until I realized it doesn't actually do anything.

reply to this message

   Board Index