2000-04-06: Impromptu Atlas map discussion: Atlas semantic maps and 2D/3D clients/media

04:05:02 <calil> i i was reading the mailing list and saw that there is a big
                        map and object editor, am i right?
04:05:16 <pug> There's a map editor?
04:05:23 <pug> Lavoie kinda did one ages ago...
04:05:42 <calil> ops
04:05:57 *** kosh has quit ([x]chat)
04:05:57 <arf> i thought the point was there isn't one and we need one
04:06:05 <calil> big map and object editor problem was what i ment..
04:06:16 <arf> hehe
04:06:20 <calil> :-)
04:06:32 <Sal> calil, yep :) they don't exist
04:06:47 <arf> does anyone use isoEdit?
04:06:58 <pug> Not in ages
04:07:07 <calil> ok, would it be hard to make one?
04:07:41 <Laurel> sort of, since it requires a file format...
04:07:44 <Sal> as for coding the software, not really calil. We have a lot of
                        programmers that could...
04:07:58 <Sal> I think the problem is the map file format
04:08:09 <Sal> (needs to be designed)
04:08:40 <pug> Details, details...
04:08:44 <arf> kosh was arranging a meeting to talk about it... dunno what
                        happened
04:08:45 <calil> ok, so it would be ok to think a little about file format
                        design?
04:08:51 <Laurel> though, you don't necessarily need the "real" file format, as
                        long as the editor's has a superset of the features.
04:09:07 <Sal> calil, definately :)
04:09:07 <arf> what was wrong with the file format now used by uclient?
04:09:21 <Sal> arf, its 2d, tilebased...
04:09:43 <arf> oops. yup. that .hs thing is a bad kluge too
04:10:13 <Sal> it actually is a usable format though. we could easily ad layers
                        and have a UO-quality 2d client
04:10:17  arf  snaps  its memory module into place properly
04:10:19 <Sal> ad/add
04:14:54  Drew (DrewNumber@cae31-203-019.sc.rr.com) has joined #forge
04:17:50  Chord-afk (~chord@cc775524-b.chmbl1.ga.home.com) has joined #forge
04:17:51  brenda  kisses Chord-afk Hello
04:18:00 ** Chord-afk is now known as Chord
04:18:04 <chuck> uclient's format probably should be 2d.  it's a 2d client
04:18:17 <chuck> up to the server to feed it 2d data
04:18:37 <chuck> or to something in the middle to translate it
04:18:59 <Laurel> i think the format we're talking about is server side...
04:19:20  Drew  hates coming in in the middle of a conversation.
04:20:13 <pug> They're discussing map formats
04:20:18 <pug> Simple ones
04:20:26 <chuck> way i see it you'd probably need multiple levels like UO has. 
                        partition the 3d space into heights
04:20:28 <Sal> chuck, I agree.  We still need to flesh out the format that the
                        2d data gets generated from, and need an editor for that format
04:20:52 <chuck> each height zone is a flat map on uclient.  where there is
                        something over it, draw it and use cutaway
04:21:39 <Drew> Hmm, this is a simple temp format, or something like the final
                        should be?
04:22:11 <Laurel> why shouldn't the 2d data be generated from the same format
                        as the 3d data?
04:22:14  chuck  doubts the transformation from 3d space to levels could ever
                        be done on the fly
04:22:26 <chuck> not unless you have a cray t3e for your server or something
04:23:02 <Sal> I guess it all depends :)
04:23:07 <arf> why limit yourself to flat levels? how about  generating and
                        arbitrary 2d slice?
04:23:17 <chuck> thats what i'm talking about
04:23:19 <arf> s/and/an/
04:23:20 <chuck> you use 2d slices
04:24:04 <calil> chuck, my school has one maby we can ask them to server for us
                         :-)
04:24:23 <chuck> and flatten the slice out.  a significant slope is still going
                        to be a problem
04:24:29 <calil> its only a t3e600 though and only 284 nodes....
04:24:33 <chuck> how you represent the slope, deal with it crossing levels
04:24:40 <chuck> you could end up with an escher painting
04:25:20 <Sal> chuck, so your suggestion a 2d voxel type thing?
04:25:25  chuck  remembers an old C64 game, realms of impossibility, where all
                        the levels had escher-like paradox topographies
04:25:57 <chuck> fun little game, really bent your brain trying to navigate
                        around
04:26:44 <Laurel> hm, how would one do "impossible" terrain...
04:27:28 <chuck> in 3d, you cant
04:27:40 * pug is now known as pug-nhrn
04:28:11 <chuck> in the isometric 2d view, you over or undercompensate for
                        perspective
04:28:56 <Laurel> hm, mazes wouldn't be much fun with overhead views either..
04:29:19 <calil> Laurel, it would if you use fog of war
04:29:26 <chuck> how so?
04:29:37 <chuck> didnt you ever do mazes as a kid in puzzle books?
04:29:41 <chuck> you had a top down view then
04:29:49 <Laurel> well, it would be a different kind of maze.
04:30:15 <chuck> in a game you just make the maze change state a lot
04:30:24 <chuck> shifting walls and puzzle sequences
04:30:37 <calil> dont you think that line of site should be implemented?
04:31:10 <Laurel> yeah. depends on implementation, i suppose...
04:31:48 <chuck> anyway a myth-like top-down engine is basically a 3d engine
04:31:55 <chuck> it's just not first-person
04:32:40 <Laurel> if the top down is "correct" only for the parts that the
                        character actually sees, then there's no problem..
04:33:49 <chuck> in a solipsistic world perhaps
04:33:59 <Sal> kosh, any luck with getting a map editor meeting organized?
04:34:03 <chuck> but in a multiplayer game, the player has to interact
04:34:04 <calil> a what?
04:34:30 <chuck> someone on level 2, which you decided was in the way of
                        player's level 1, might decide to throw a fireball
04:34:40 <chuck> case in point: a high wall
04:35:32 <Laurel> huh? you mean the player should be able to see things the
                        character can't see?
04:35:40 <chuck> player is perched on a ledge in this wall.  this wall was in
                        the way of another player's view.  only thing you could do is have
                        the player floating in mid-air
04:37:00 <chuck> ultima7 and 8 avoided this sort of problem by not putting any
                        kind of detail on south or west walls
04:37:01 <koshhome> ah I need to post that Sal
04:37:07 <Laurel> oh, you mean objects you can see only part of?
04:37:27 <chuck> they even had a cute made up story about why houses have no
                        doors on the north or east sides
04:37:42 <chuck> or er, west, the view was skewed to show east walls
04:38:05  Drew has quit (Leaving)
04:38:58 <chuck> so ultima7 and 8 were like walking around tv sets, two walls
                        always missing
04:39:19 <Sal> kosh, gotcha.  I think I'm going to start a thread about it
                        though...
04:39:28 <koshhome> go for it
04:39:41 <Sal> it about time we get the ball rolling with it :/ 
04:39:45 <koshhome> have to check all the times
04:39:53 <koshhome> many client developers did not reply with times
04:40:25 <Azhrei> he hehe no time any time :) I'm not here weekends and thought
                        that was when you were doing it ;)
04:40:28 <koshhome> I don't want a spec that is designed for just certain
                        clients however it seems that can't be helped right now
04:40:33 <Laurel> just assume everyone else doesn't care and schedule it..
04:40:46  Azhrei  fears a spec that supports only one client
04:40:58  Azhrei  nods at laurel
04:41:01 <koshhome> it will at least support a few
04:41:10 <chuck> well only one spatial model can really be official
04:41:17 <chuck> anything else is an approximate translation
04:41:22 <Azhrei> chuck you mean text vs 2d vs 3d?
04:41:27 <koshhome> it needs to be done and if no one else comes that will be
                        what we get
04:41:34 <chuck> right.  text i see as a complete pipe dream
04:41:34 <Sal> right, that's why I wanted to start a thread though. So we get
                        everyones input for sure,
04:41:39 <Azhrei> chuck why so?
04:41:51 <koshhome> okay sal do you want to try it that way?
04:42:15 <chuck> Azhrei: you translate a 3d world into text
04:42:16 <koshhome> see if you can get it started on email and later have an
                        irc meeting once there is a more concrete design?
04:42:29 <chuck> text everquest.  try it
04:42:34 <koshhome> no you translate an atlas stream into text
04:42:40 <Sal> that's how it should be done, I think. I know people are going
                        to miss the map meet... and miss out on the design if its done like
                        that
04:42:40 <Laurel> we need to define the scope of a "map format" first...
04:42:51 <chuck> some things are untranslateable into meaningful text
04:42:53 <koshhome> the server has a map parses it and sends the info to the
                        client
04:42:56 <Sal> kosh, yep... that would work
04:42:56 <koshhome> the client does not get the map
04:42:59 <chuck> you'd end up better off reading the atlas stream
04:43:13 <calil> i think all data should be transferd as 3d no matter what
                        client. then its the client choice what to show the user.
04:43:14  chuck  pictures something like the funky japanese display in The
                        Matrix
04:43:23 <koshhome> sal I don't know how to make a map format I was just trying
                        to get the client developers together
04:43:36 <koshhome> yup all data transmitted is 3d
04:43:42 <koshhome> the client dispays what it can
04:43:43  Sal  nods
04:43:56 <Sal> no a map meet is a great idea, we should still do it
04:44:03  bryce (~bryce@ppp245.neptune.net) has joined #forge
04:44:05 <brenda> hi bryce
04:44:12 <koshhome> okay how about start a thread on clients
04:44:31 <koshhome> and we can meet not this friday but next friday to discuss
                        what came up on the list
04:44:40 <Sal> but I think a posting of all our previous designs (mim, amis,
                        uclient's, etc.) and then a thorough review would be best
04:44:50 <Laurel> hm, it's sort of a server issue too...
04:47:07  Peregrine (~tigger@chrisl.dsl.speakeasy.net) has joined #forge
04:47:07 <brenda> Peregrine can I help you?
04:47:36 <Sal> kosh, sounds good to me
04:47:49  chuck  should be able to subscribe to the forge lists again once he
                        gets off the kde lists
04:48:23  chuck  keeps reading "map" in here as "mmap"
04:48:28 <koshhome> chuck just use procmail
04:48:37 <chuck> been working with that particular syscall too long :-/
04:48:42 <chuck> koshhome: i do use procmail
04:48:47 <chuck> i never read the kde lists anyway
04:49:26 <Azhrei> hmmm ok, well map format is the tuffest thing to do ;) once
                        that is settled the rest is just plot and technical detail ;)
04:49:35  chuck  gets to bang on cyrus imapd tomorrow since he just found the
                        "reconstruct" command
04:49:52 <chuck> going to corrupt my mail in every way imagineable
04:50:10 <chuck> well a copy of it :)
04:50:45 <chuck> probably flood the thing with a couple thousand simultaneous
                        flood connects
04:50:45 <chuck> muahaha DOS-attacking my own server
04:50:59  chuck  </babble>
04:55:15 <Sal> kosh, I'll start getting stuff together for the post now. I
                        think I'll throw in simple descriptions of each format we've come up
                        with thusfar, plus others... I think UO's format is worth a look and
                        also one of the pure 3d ones like .3ds or .ase
04:55:40 <Azhrei> who about .obj format?
04:55:47 <koshhome> okay that will work well sal
04:56:11 <Azhrei> anybody know if order of xml tags is important, or is it
                        interpreted correctly as long as the tag is correct?
04:56:19 <Sal> anything else?  hmm obj I dont really know about but I assume
                        its pretty similair to 3ds/ase
04:57:00 <Azhrei> ie: <map><string>str1</string><string>str2</string></map> vs
                        <map><string>str2</string><string>str1</string></map>
04:57:16 <Sal> right, that's an issue to talk about Axhrei... if we should go
                        XML, binary, or some custom ascii with binary references... should we
                        use Atlas syntax? etc.
04:57:19 <Azhrei> sal: I htink obj supports boning and some other animation
                        things people were more interested in
04:58:10 * pug-nhrn has quit (Leaving)
04:58:24  chuck  . o O ( boning support? )
04:58:53 <Laurel> az: if that's atlas, map is ordering-independant
04:59:17 *** Diablo-D3 (~Diablo-D3@63.163.40.154) has joined #Forge
04:59:34 <Diablo-D3> hey all
04:59:51 <Sal> Right, then we need to decide client specific stuff.  3d needs
                        an object format, 2d does also for complex things I assume, that
                        can't be described in the mapfile in a general enough way
04:59:59 <Azhrei> laurel"thanks thats what I was after :)
05:01:01 <Azhrei> sal: I'd just like to make sure we stay as client neutral as
                        possible... defining the client to much via the protocol for maps
                        would be a bad thing IMHO
05:01:38 <Diablo-D3> yeah
05:01:45 <Azhrei> ie the protocol should exist in a way such that there is room
                        for interpretation so clients can be different from each other
05:01:49 <Diablo-D3> objects should all be contained in there own files
05:01:51 <Sal> that's a good point.  Mixing the protocol and mapfile format
                        needs to be discussed
05:02:19 <Azhrei> the way I see it the map soemwho needs to be describable
                        using only syntax present int he protocol
05:02:42 <Azhrei> s/soemwho/' '
05:02:52 * You are now known as aloril
05:03:59 <Laurel> I still think we need to define the scope of the "map format"
                        before discussing specifics..
05:04:09 <Azhrei> would be good I think
05:04:21 <Azhrei> and the purpose of the map format
05:04:42 <Diablo-D3> yeah.....
05:04:47 <Diablo-D3> like.. hmm
05:04:54 <Diablo-D3> how is the "ground" gonna be done?
05:05:11  rillian (~giles@raj.phys.sfu.ca) has joined #forge
05:05:14 <Diablo-D3> thru textures?
05:05:14  brenda  shows rillian to a chair
05:05:19  Azhrei  doesn't think thats what laurel meant by scope ;)
05:06:26  BloodSport has quit (Connection reset by peer)
05:06:35  BludSport (~blah@cli-02-167.eclipse.net) has joined #forge
05:06:38 <brenda> BludSport can I help you?
05:08:02 <aloril> about map format: server takes care of meaning part, rest is
                        media and can vary?
05:09:19  Azhrei  would like it to be that way
05:10:34 <Sal> aloril, right. but we need to design the mapfile format that the
                        server loads, no?
05:10:43 <aloril> Sal: yes
05:11:17 <aloril> and that part needs to go over wire too: because otherwise
                        server could't to earthquakes, house building, etc..
05:12:12 <chuck> you can always define a base map
05:12:26 <chuck> then for events that change the base map, you give fair
                        warning ahead of time
05:12:37 <chuck> like on connect
05:12:45 <Peregrine> But what if there is no fair warning
05:12:50  Azhrei  thinks having set in stone map is bad, everything should
                        change the world in a dynamic and permanente way
05:12:51 <Peregrine> Like a PC casts an earthquake spell
05:13:08 <Peregrine> or they begin to build a house.
05:13:11 <Azhrei> or lightrs a forest fire and turns a forest into a plain
05:13:15  chuck  imagines individual buildings might not work well that way,
                        but new mountains tend to not spring up that often
05:13:33  chuck  personally thinks of a house as an object, not base terrain
05:13:38 <Azhrei> that would happen relativly quickly , the forest thing, mtns
                        too if volcano
05:13:47 <chuck> mostly i'm thinking of stuff that'd change a terrain mesh
05:14:03 <Peregrine> Well the forest fire might not turn it into a plain right
                        away
05:14:05 <Azhrei> volcanoe and earthquake spells/ natural phenomenon
05:14:13 <Peregrine> More likely it would change it into a charred area
05:14:15 <Peregrine> With black soot laden ground.
05:14:29 <chuck> guess if you want a map like populous
05:14:46 <chuck> forest fires tend to not burn the forest to the ground
05:15:00 <Peregrine> Anyways it's been decided that PC could cause radical map
                        changes so the map has to be easily changable on the fly
05:15:07 <Azhrei> one of the big questions is that you can view the world as
                        continuous planar, ie poulous, or container based with rooms etc...
05:15:09 <chuck> they leave a lot of blackened tree trunks
05:15:31 <Diablo-D3> planar kicks ass
05:15:34 <Azhrei> that seems to be a major question to me... continous vs
                        discontinous
05:15:46 <Diablo-D3> CONTINOUS ALL THE WAY BABY!
05:15:50 <Diablo-D3> :P
05:15:56 <Azhrei> discontinous is much easier to handle on a communications
                        level and for changes etc...
05:16:24 <Diablo-D3> yeah well. :P
05:16:38 <Azhrei> and for description etc, but doesn't work well at describing
                        outdoor settings w/ little to no natural borders... it also lends
                        itself poorly to user modification in real time
05:16:42  Diablo-D3  hates discontinous
05:16:58 <Diablo-D3> now, on the other hand if the map was made of many smaller
                        maps....
05:17:06 <Azhrei> what do other people think about discont vs cont?
05:17:09 <Diablo-D3> but it still acts continous....
05:17:21 <Diablo-D3> er
05:17:25 <Diablo-D3> wait
05:17:29 <Diablo-D3> atually, discont would work better
05:17:35 <Azhrei> you need to do overlapping of some kind, I hated the cache
                        loads in UO and everquest
05:17:38  Peregrine  does not know enough to make have an opnion.
05:17:43 <chuck> that's basically how UO works
05:17:55 <Diablo-D3> either to handle blahblahblah what azhrei said, and the
                        client can interprete it any way it wants to
05:17:59  Azhrei  played a real early version of UO
05:18:37 <Diablo-D3> like, lets say you have a client who makes the world act
                        continus...
05:18:38 <aloril> Diablo-D3: container map version is basically "combine
                        several small maps" ;-)
05:18:49 <Diablo-D3> it could download all the non coninuos segments....
05:18:52 <Diablo-D3> heh
05:18:56 <aloril> and is very simple to convert to continuous one
05:19:09 <aloril> btw... we could do even this now:
05:19:22 <aloril> server side meaning map wouldn't change much, but 2D would:
05:19:41 <aloril> we could use old 2D iso format for each container, house,
                        tree, etc..
05:19:59 <aloril> ie each separate object would be either sprite or tilemap
05:20:15 <aloril> and we can probably use some perl script to translate it to
                        new tile format
05:20:32 <Azhrei> What I wonder about is if being able to do a 2d and a 3d
                        client is causing the main problem...
05:20:50 <Diablo-D3> it might be
05:20:59 <Azhrei> Height data being a good example./.. in 3D it is height field
                        and good.... however w/ 2D it is either pass or not passable
05:22:34 <DragonM> 2D vs 3D client...
05:22:37  DragonM  scrolls back.
05:22:46 ** Drew (DrewNumber@cae31-203-019.sc.rr.com) has joined #forge
05:22:48 <brenda> hey Drew, some coffee?
05:23:03 <Diablo-D3> hey drew
05:24:38 <DragonM> Hmm.
05:25:07 <DragonM> I see some discussion regarding how to make a continuous
                        world.
05:25:31 <DragonM> A good ROAM implementation would do nicely for the
                        requirements I seem to be seeing.
05:25:34 <Azhrei> yep yep yep and if, how and if
05:25:41 <Azhrei> ROAM??
05:25:43 <Laurel> roam?
05:25:58 <DragonM> I believe a ROAM implementation is integrated in
                        CrystalSpace now.
05:26:05 <DragonM> And lemme look up the acronym.  :)
05:27:59 <Azhrei> usually the added overhead of calculating visibility in 3d
                        makes it hard to do real time 3D world description
05:28:12 <DragonM> Real-time Optimally Adapting Meshes.
05:28:20 <Diablo-D3> ooh
05:28:20 <Diablo-D3> i like it
05:28:24 <chuck> sounds funky.  what is it?
05:28:25 <Laurel> got a url?
05:28:47 <Azhrei> This is why quake etc have BSP which is basically a compiled
                        form of visibility look up tables
05:28:56 <DragonM> It's hardware accelerated, very compatible with OpenGL's
                        display lists and fans for even more acceleration, and optimized how
                        "pretty" a landscape is as the character moves.
05:29:02 <DragonM> http://www.gamasutra.com/features/20000403/turner_01.htm
05:29:09 <chuck> oooh
05:29:23 <DragonM> That article includes stand-alone source code, sans some
                        optimizations.
05:29:48 <DragonM> I think it would be relatively difficult to utilize ROAM
                        data for a 2D engine, however.
05:30:34 <DragonM> optimizes how pretty, even...
05:30:37 <DragonM> typo.
05:30:52 <DragonM> It's specifically designed for landscape representations, of
                        course.
05:31:40 <Diablo-D3> atually, i wouldnt mind that much if it was a compleatly
                        3d world..
05:31:47 <DragonM> Using it to represent dungeons is possible, but would
                        require significant adaptation, as it is geared for only a single
                        point per vertical axis.
05:32:06 <DragonM> i.e. rendering the roof would be impossible in the existing
                        implementation.
05:32:21 <Sal> ROAM is pretty cool for terrain stuff.  its a pretty simple
                        algorithm to implement too.
05:32:32 <Azhrei> hmmm I would very much like to make sure that a 2D client
                        still remains a def. posibility
05:32:34 <DragonM> It's a deformable terrain, too.
05:32:46 <Sal> it doesnt handle continuity though...
05:32:47 <Azhrei> since that is what I intend to write
05:33:04 <aloril> hmm.. maybe as part for 3D media?
05:33:28 <aloril> what about this for meaning map format:
05:33:34 <DragonM> I think it should be possible to define spell effect
                        algorithms that could be triggered, and then implemented on the
                        client and server side independently, thus foregoing the necessity of
                        the server forwarding all of the new terrain data to the client 
05:33:35 <aloril> containers
05:33:38 <DragonM> in some giant burst of data.
05:33:51 <DragonM> What definition of continuity, Sal?
05:34:00 <aloril> bottom level object is either terrain or 'point' object
05:34:18 <aloril> terrain: grid of height data + 2D/3D/etc.. media 
05:34:39 <aloril> 'point' object: location + .... media
05:34:46 <aloril> and media can be local too
05:35:10 <DragonM> ~~~~~
05:35:42 <aloril> hmm... well terrain is not usually bottom level object in
                        containers though..
05:36:17 <aloril> cambria->agrilan->forest->house->buddy->backpack->purse->money
05:36:22 <DragonM> Unfortunately, 2D engines do not lend themselves at all to
                        modeling worlds.
05:36:32  Azhrei  agrees
05:36:40 <DragonM> Land SLOPES.  And 2D engines have fits trying to do that.
05:37:04  Azhrei  thinks but in the end all that matters for 2d and 3d is
                        whether it is passable or not
05:37:19 <Diablo-D3> hmm....
05:37:22 <DragonM> I thikn that's only the case if your 2D artists are really
                        good.
05:37:32 <Azhrei> huh??
05:37:40 <Diablo-D3> thats not entirly true
05:37:47 <Azhrei> how so?
05:37:49 <aloril> DragonM: well.. we gradually add slopenesness and let it to
                        be gradually solved ;-)
05:37:50 <DragonM> Erm.
05:37:59 <Diablo-D3> you can make a psudeo 3D engine for a 2d system
05:38:14 <aloril> for big changes we can use media in different zoom factor:
05:38:15 <DragonM> Erm.  What do you mean by 2D engine, Azhrei?
05:38:21 <Azhrei> thats what I was thinking, you keep track of the info, or the
                        server does, and not all of it is whon
05:38:23 <DragonM> Isometric in Diablo style?
05:38:37 <Diablo-D3> possibly. ive never seen it done... but it is possible
05:38:41 <Azhrei> DragonM:well, diablo, Warcraft, or even Ultima 7/8ish.///
05:39:00 <DragonM> Ok, so fixed field of view, tile-based landscape graphics
                        and sprite-based character graphics.
05:39:22 <Azhrei> yeah more or less... I'd be willing to do some interesting
                        things witht he fixed landscape tiles though
05:39:33 <DragonM> Characters are easy to deal with.  Render the 3D engine's
                        media into a 2D sprite and poof, you're done.
05:39:46 <DragonM> Those landscape tiles are the big stumbling block I see.
05:39:55 <Azhrei> It'd be nice if you could use your own media if you felt like
                        it...
05:40:02 <Azhrei> why are landscape tiels so big a deal?
05:40:07 <DragonM> If you're using something with the granularity of a ROAM
                        implementation, mashing it so that 2D tiles can be used to cover it
                        would be ugly.
05:40:19 <Diablo-D3> no it wouldnt atually
05:40:23 <DragonM> A ROAM implementation typically has a MUCH higher
                        granularity than a 2D system.
05:40:24 <Diablo-D3> it atually might be easy
05:40:38 <Azhrei> aha...   so the problem is level of detail differences then
                        more then 2d vs 3d
05:40:45 <Diablo-D3> all you need to do is render, and skew tiles
05:40:49 <DragonM> Well, not entirely.
05:41:06 <DragonM> If by that you mean modify tile graphics on the fly in code,
                        that's a very bad thing to do, Diablo.
05:41:16 <Diablo-D3> heh
05:41:21 <DragonM> I did it, accidentally, in an isometric engine I implemented
                        under DirectX.
05:41:24 <DragonM> The framerate tanked.
05:41:27 <DragonM> Worse than tanked.
05:41:27 <Azhrei> diablo in fact it is just about impossible to do fast enough
                        not to bog the system...
05:41:29 <Diablo-D3> heh
05:41:30 <DragonM> it bit the dust.
05:41:49 <Azhrei> We tried to do some of that in a space game he he hehe
05:41:55 <DragonM> And that was only a simple on-the-fly mirroring that was
                        being done too often.
05:42:07 <DragonM> Utterly destroyed it.  Went from 60 fps to under 5 fps.
05:42:17 <Diablo-D3> brb
05:42:21 <DragonM> 2D engines can't modify tiles.
05:42:43 <Azhrei> however, there are only so many combinations of info... for
                        height, so if you predefine enough, or can do soemthing inteesting
                        through combination using alpha chganels you might manage it
05:42:46 <DragonM> So the question is, is there a reasonably small minimum
                        number of tiles that can be used to represent some subset of the
                        slopes possible in a 3D ROAM world map?
05:43:15 <Azhrei> you ought to manage with 12 tiles or so....
05:43:27 <Azhrei> flat, going down on all sides, and going up on all sides
05:43:33 <DragonM> In a 3D ROAM world map, differences in height from one data
                        point to the next can be miniscule, and vary radically in each of 8
                        directions.
05:44:05 <Azhrei> yeah but we don't care about height difference at a really
                        high levle, only as it neesds to change over distance, and to points
                        where you can't cross it b/c the slope is to much...
05:44:30 <Azhrei> we can let the server take care of physics like movement
                        rate, and visibility due to height differences
05:44:50 <DragonM> Well yes, when going from 3D high density data points to a
                        2D representation, you necessarily take some group of 3D points, like
                        for instance 5 on a side, average their heights and angle, and select
                        a tile that will cover that area.
05:45:26 <DragonM> If it was a matter of just averaging heights and slapping
                        down flat tiles in a grid, it'd be simple.
05:45:38 <Azhrei> of course that means that a 2D client may end up being more
                        cpu intensive then 3D b/c you deal with all the 3d data like a 3d
                        client and then modify it in addition
05:45:47 <DragonM> But if you do that, it's going to look like that shareware
                        game on the 286 whose name I can't reemeber.  :)
05:45:50 <DragonM> remember, ven.
05:45:51 <DragonM> Gaps everywhere.
05:45:57 <chuck> if a 2d client has to do this much interpretation of 3d data,
                        why call it a 2d client?
05:46:05 <DragonM> You wouldn't do it on the fly.
05:46:13 <Diablo-D3> back
05:46:22 <DragonM> You would essentially down-sample the 3D data, and store it
                        off to another format for the 2D client.
05:46:27 <Azhrei> what if all tikles are seperated by some amount of space and
                        intermediary non tiles are used to connect between different height
                        ares..
05:46:28 <chuck> you may as well write a top-down 3d client ala myth that just
                        renders the slope
05:46:51 <Azhrei> Dragonm, that doesn't satisfy the on fly change requirement
05:46:56 <DragonM> Rather than creating from scratch two complete maps, you
                        would just make one 3D map, and then use code to mash it.
05:47:07 <DragonM> For an entire world, you have to pre-sample.
05:47:11  Azhrei  thinks the main point of 2d is to cater to poorer cpu
                        players
05:47:15 <DragonM> On the fly changes are not going to cover whole continents
                        however.
05:47:28 <Azhrei> would be nice if they could....
05:47:29 <Diablo-D3> why cater to poorer cpu players?
05:47:32 <DragonM> It should be possible to do on the fly changes for some
                        small area in a reasonable amoutn of time.
05:47:35 <Azhrei> if you only see things as the server tells you they exist....
05:47:37 <Diablo-D3> isnt doom 3d?
05:47:50 <Azhrei> software.... yes
05:47:54 <Diablo-D3> why cant we do a uber low end 3d engine?
05:48:07 <dmitryd> doom is not 3d
05:48:16 <Azhrei> I like 2d... I'm not a huge 3D fan, being 3D just to be 3D is
                        boring
05:48:26 <Laurel> it's like.. 2.5d. or 2.1d.
05:48:32 <DragonM> While you're busy wowing the audience with fancy spell
                        effects, all of which are prerendered for the 2D engine, your CPU can
                        be busy cranking out downsamples of 3D data.
05:48:34 <aloril> well... server needs relatively simple too, otherwise it
                        might get bogged in calculated movement change for every stone ;-)
05:48:44 <Diablo-D3> damnit
05:48:51 <Diablo-D3> this kinda sucks
05:49:02 <Azhrei> ok we need better faster cdistributed computers :)
05:49:04 <DragonM> What does?
05:49:09 <aloril> and have accurate 3D media ?
05:49:12 <Diablo-D3> this whole thing
05:49:25  Azhrei  doesn't like to see such negativity
05:49:31 <DragonM> Yeah sure we do.  And less than 1 millisecond lag
                        connections from anybody to anybody else on the Internet.
05:49:40 <Azhrei> exactly :)
05:49:46 <aloril> does server needs to have very accurate map?
05:49:55 <chuck> i should say so
05:49:59 <chuck> it's the authority
05:50:04 <aloril> let client do 0.1m approximations itself
05:50:04 <DragonM> And voice compression algorithms that can deliver CD quality
                        audio in half a kilobit per second.
05:50:07 <DragonM> Yeah.
05:50:15  DragonM  snorts.
05:50:39 <Azhrei> maybe we need to come up with a fundementally new way of
                        viewing a world space.
05:50:49 <DragonM> Azhrei is after creating a client that does not require 3D
                        hardware acceleration to be playable, as near as I can figure.
05:50:57 <aloril> so server keeps only essential info and let client handle
                        minute details (==chrome maps==XD media)
05:50:59  Azhrei  nods at DragonM
05:51:08 <DragonM> ROAM implementations require 3D hardware in a big way.
05:51:16 <DragonM> A decent voxel engine requires BIG CPU to do well.
05:51:17 <Diablo-D3> heh
05:51:24 <Diablo-D3> roam sucks then
05:51:38 <chuck> DragonM: outcast was a voxel engine, runs fine on a P2/400
05:51:38  Azhrei  would love to be able to play on 486dx75 laptop :)
05:51:39 <DragonM> ROAM scales however, Diablo.
05:51:56 <aloril> DragonM: so prerednering few orientations for tiles and
                        combining them doesn't work?
05:52:04 <DragonM> It can use as little horsepower as a Voodoo1, or as much as
                        an SGI.
05:52:23 <Azhrei> aloril: you can do that, the qustion is just how many titles
                        are nec.
05:52:26 <Diablo-D3> can it survive on a p90?
05:52:28 <DragonM> Yah, outcast has a voxel engine that runs on a P2 400. 
                        Which is a far cry from Azhrei's target system.  :)
05:52:41 <chuck> know what?  Azhrei's target system is a doorstop
05:52:46 <Azhrei> it may be that we just want to much flexibility???
05:52:46 <aloril> Azhrei: I was asking about those gaps
05:52:48 <chuck> no, i have faster doorstops than that
05:52:50 <DragonM> If your player can tolerate the resolution sure, Diablo.
05:52:52 <Diablo-D3> know what? many people have doorstops
05:53:04  Diablo-D3  atually doesnt mind 320x200
05:53:10 <Azhrei> aloril: gaps are a different thing, if yuou don't have
                        prerendered height conversion tilses
05:53:11 <chuck> the phrase that comes to my mind is "all things to all people"
05:53:13 <DragonM> ROAM can be done on a P90 with a Voodoo1.  It just won't
                        look too great.
05:53:28 <Diablo-D3> heh
05:53:29 <chuck> given infinite money, development resources, and time, you can
                        be all things to all people
05:53:39 <aloril> Azhrei: ahh.. then artist needs to adjust it beforehand?
                        hmm.. then it could work?
05:53:46 <DragonM> Prerendering a few orientations for tiles and combining them
                        does work, in the extreme case of infinite tiles.
05:53:49 <DragonM> Which we call 3D.  :)
05:54:01 <Azhrei> yes it can and does work, see Sid Meirs use of such a concept
                        for Alpha centauri maps
05:54:04 <DragonM> Scaling that back can also be done.
05:54:15 <DragonM> There is a limit to how it scales back, however.
05:54:16 <Diablo-D3> what designs will we have for clients?
05:54:30 <aloril> DragonM: hehe... well I was thinking only few orientations:
                        like one for each slope direction or like
05:54:31 <Azhrei> interesting ways to do it are use 3D only for terrain ala
                        populous, with characters etc still done using sprites...
05:54:35 <Diablo-D3> i mean, like, iso 3d, full 3d, overhead 2d.....
05:54:44 <DragonM> If the world model is 3D, essentially, Azhrei's client would
                        look a lot like Simcity 2000.
05:55:14 <DragonM> Or yes, like Populous.
05:55:25 <Azhrei> but that still requires a 3D accelerator...
05:55:27 <DragonM> An approximation could be done that would work.
05:55:33 <DragonM> No, neither required 3D hardware.
05:55:38 <DragonM> Populous ran happily on my 286.
05:55:53 <Azhrei> I guess we ought to decide whether it is really possible to
                        make a 2D and 3D client connect to the same server...
05:55:58 <DragonM> However, that approximation would NOT look good in
                        comparison with the 3D version.
05:55:59 <aloril> DragonM: it doesn't matter if it differs from actual map 0.3m
                        for example
05:56:01 * Azhrei  was tlaking about populous the beg
05:56:10 <DragonM> it would differ by quite a bit more than that, aloril.
05:56:11 <aloril> only needs to visually be somewhat sensible
05:56:34 <DragonM> I was talking about Populous, no subtitle, no sequel number,
                        no nothing, Azhrei.  :)
05:56:39 <Azhrei> or could a 2d map just ignore height unto the slope is so
                        great as to block movement???
05:56:41 <aloril> well.. as long client handles actual height and know what is
                        tile height I guess it can differ much more too
05:56:54 <DragonM> No Azhrei.  That's not reasonable.
05:57:00 <Azhrei> why not??
05:57:11 <arf> a 2d client should deal wioth a surface, regardless of slope
05:57:15 <DragonM> Some distortion is ok.  That would be a LOT of distortion. 
                        :)
05:57:29 <Azhrei> as long as it is still playable does it matter though??
05:57:38 <DragonM> A gentle slope that extends across the entire Cambrian
                        valley wouldn't be visible at all.
05:57:39 <aloril> well... what about this:
05:57:39 <Laurel> if there's no functional difference, why does it matter,
                        really?
05:57:40 <Diablo-D3> we should have 2 different maps then
05:57:49 <aloril> 1) server has height data
05:57:54 <DragonM> It matters because there would be a functional difference.
05:58:02 <DragonM> A hill would be passable as far as the server is concerned
                        by both clients.
05:58:04 <aloril> 2) there is 3D media for clients that is fancy
05:58:15 <DragonM> However in the 3D client, it would not be possible to stand
                        on one side of the hill and see the other side.
05:58:21 <aloril> 3) let 2D people solve problems as best as they can
05:58:25 <aloril> ;-)
05:58:27 <DragonM> If you implement the 2D client eh way you suggest, you WOULD
                        be able to do that, and in fact would see no hill at all.
05:58:29 <DragonM> That doesn't work.
05:58:30 <Azhrei> aloril :P
05:58:39 <Diablo-D3> 4) screw 2d, and make a quake 1 level engine. :P
05:58:48 <Azhrei> true, you would just get blank spots b/c the server wouldn't
                        let you see past the hilll...
05:58:50 <aloril> hey... if there is no challenges, then.. what those people do
                        that love challenges? ;-)
05:58:55 <Laurel> so someone will write a 3d client that allows you to see past
                        the hill..
05:59:01 <DragonM> Yes.  Which would be really bizarre.
05:59:13 <Diablo-D3> laurel: the server will never tell the cleint what is on
                        the other side, tho
05:59:23 <Laurel> well then the 2d client can't see it.
05:59:29 <DragonM> Right.  Server is going to cull as much as possible to
                        reduce network traffic.
05:59:30 <Diablo-D3> exactly
05:59:30 <Azhrei> ok, I'm gonna think about this for a bit...
05:59:38 <DragonM> If you can't see it, you're not going to hear about it
                        across the wire.
05:59:45 <arf> visibility is same whether 3d or 2d, no?
05:59:52 <Diablo-D3> arf: correcnt
05:59:56 <Diablo-D3> er correct
05:59:58 <DragonM> I think a Simcity 2000 or Populous style 2D engine could be
                        used, Azhrei.
06:00:00 <Diablo-D3> damnit. :P
06:00:01 <aloril> what about this problem: really big slope or standing on top
                        of mountain and looking far away: solution for 2D client?
06:00:16 <aloril> (really big slope: like 200m drop in 10m)
06:00:27 <Azhrei> aloril: still server gives same visibility as before...
06:00:29 <DragonM> It would use a single angle to join always flat tiles, but
                        it could be a reasonable, if somewhat blocky approximation of a 3D
                        world.
06:00:31 <arf> aloril: lower resolution tiles farther away., same as 3d
06:00:38 <aloril> arf: exactly!
06:00:50 <aloril> and container model fits there quite nicely:
06:01:00 <aloril> just have 2D maps for different zoom levels:
06:01:06 <DragonM> Standing on top of a mountain and looking far away isn't
                        possible in the 2D client, aloril.  :)
06:01:07 <Azhrei> The big question should be what format, and leave client
                        implementation out as much as possible...
06:01:11 <aloril> it's needed for 3D clients and overview maps too ;-)
06:01:17 <DragonM> The 2D client has a fixed view angle, which precludes
                        vistas, permanently.
06:01:32 <arf> DragonM, how so?
06:01:39 <Diablo-D3> wtf cant we drop iso-3d?
06:01:41 <aloril> DragonM: well.. 2D client can have 'zoom' button
06:01:44  Azhrei  realizes a big prob is that 2D usually has omnicient view of
                        sorts...
06:01:52 <aloril> (or unzoom in this case)
06:01:59 <Diablo-D3> arg, im going to bed
06:02:05 * Diablo-D3 has quit (Leaving)
06:02:16 <DragonM> Ok, you can zoom.  Or unzoom.
06:02:21 <DragonM> But you're never ever going to be able to see the sky.
06:02:31 <DragonM> Zoom does not affect angle.
06:02:34 <DragonM> Only magnification.
06:02:38  Azhrei  feels that there is substantial division on the issues
                        regarding multi client ability... lets not get to worked up folks :)
06:02:43 <Laurel> no reason it can't have multiple fixed views...
06:02:49 <DragonM> 2D clients have severe limitations.
06:03:10 <aloril> so what I'm saying is that 2D is unsolved problem for all
                        cases: lets separate 2D issues from server and 3D client issues and
                        let people to come up with ingenious solutions ;-)
06:03:12 <DragonM> Plenty of reason.  On Azhrei's target system, the tile count
                        to accomodate multiple fixed views would quickly become unacceptably
                        high.
06:03:29 <arf> Also, there should be possibility for 1D clients: mud-style 
06:03:41 <DragonM> That's easy.
06:03:45 <aloril> arf: yes... thats text media
06:03:51  Azhrei  htinks read the atlas protocol stream??
06:04:02 <aloril> and text media is another one that needs lots of inventions
                        too ;-)
06:04:06 <DragonM> Terrain gets tossed out the window, except for specific
                        features, like rivers and canyons.  :)
06:04:15 <arf> if you can type fast enough to talk Atlas, why not? :)
06:04:17 <Azhrei> why can't 2D do that also then?
06:04:27 <aloril> DragonM: yes... and that is why sever map has meaning
06:04:34  Azhrei  azhrei dons his mind to atlas hat and starts playing with
                        cyphesis
06:04:43 <Laurel> really? it's not just (# of views)  (tiles for 1 fixed
                        view?)
06:04:53  DragonM  rests his chin on his hands and thinks about aloril's
                        question.
06:05:12 <Azhrei> but like aloril said, implementation shouldnt be the focus,
                        let the ingenous client developers figure out how to do it...
06:05:31 <Azhrei> the qyuestion is how to best portray the data...
06:05:40 <Azhrei> in as flexible a format as possible
06:05:43 <DragonM> All I can think of is the previous hill example, aloril.
06:06:07 <DragonM> The text description a text-only player sees may or may not
                        mention the hill, but it definitely won't mention stuff on the other
                        side of the hill.
06:06:27 <aloril> DragonM: server tells client that here is hill, it has this
                        height data and here is media server
06:06:36 <arf> well, since the hil is the most prominent feature, it should be
                        mentioned
06:06:39 <DragonM> This fulfills the view-blocking function of the hill without
                        having some obnoxious gap as in a 2D client that just refuses to show
                        you anything at some odd distance away because there's a hill that's
                        not represented there.
06:06:40 <Azhrei> the mud gets back to the continous vs discontinous debate...
06:06:57 <DragonM> Nobody has told me what is meant by continuous around
                        here....
06:07:23 <aloril> I guess continuous==one big height field
06:07:28 <arf> discontinuous: unexplained gaps in the data
06:07:29 <Laurel> hm, it all comes down to the granularity of objects.
06:07:34 <aloril> vs discontinous==above partitioned
06:07:37 <DragonM> The best way to portray the data is a high granularity
                        height map.  highest common denominator, that is.
06:07:42 <Azhrei> if you have a bunch of seperate rooms this is discontinous,
                        b/c you can describe each room seperately, where as a 100 mile wide
                        plain is continouse because it is to big to simply describ the entire
                        thing at once
06:07:59 <DragonM> Oh.  One BIG height field in RAM at the same time will not
                        be usable in Dural.  Forget it.
06:08:02 <aloril> and I'm for discontinious: it's simple to translate it to
                        continious one as long as they use same base
06:08:03  Azhrei  thinks laurel hit it on the head
06:08:08 <DragonM> Considering it is ridiculous.
06:08:37 <arf> clipping of view is a distinct issue from generating what you
                        should be able to see
06:08:38 <DragonM> Partitioning is the only reasonable solution.
06:08:53  DragonM  considers 3D clipping...
06:09:04 <DragonM> Hmm.  Feasible.
06:09:12 <Azhrei> a question is how you view terain as an object and and at
                        what level you can view its granularity...
06:09:35 <DragonM> In a good ROAM implementation, you load the nearest, say
                        100m to the highest level of detail available for the terrain.
06:09:46 <DragonM> The farther you get, the less you load.
06:10:04 <Azhrei> but that is a continous description, not a discontinous
                        object based description with varying levels of detail.
06:10:09 <aloril> DragonM: sounds somewhat similar to container model:
06:10:24 <DragonM> As you move, you dynamically load and unload, in some
                        reasoanble sized chunk, more data in the direction the player is
                        walking, and less in the direction they're leaving.
06:10:42 <aloril> DragonM: near you get 1m2 terrain data (say forest
                        container you are at and maybe few neightbour ones depending on size)
06:11:10 * hrothgar (^hrothgar at toad.bitstreet.net) has left #forge
06:11:31 <aloril> DragonM: for things further away server sends only containers
                        on top of that (village, etc... containers instead of
                        field+hill+forest+lake)
06:11:31 <DragonM> If by container you mean some specific A meter X B meter
                        area, that's precisely what you do.
06:11:34 <Azhrei> ar we getting to hung up on height data?
06:11:54 <aloril> DragonM: even further away tell only big area containers,
                        like big cities or forest, etc..
06:11:59 <aloril> DragonM: etc..
06:12:16 <DragonM> A forest or mountain far enough away is going to be a faint
                        haze in ROAM.
06:12:18 <aloril> DragonM: for starts only tell generic sky container ;-)
06:12:32 <DragonM> A city is going to be a slightly dirtier haze, at the same
                        distance.
06:12:34 <arf> hmm, when you say container, does the container have something
                        like an encapsulated thumbnail?
06:12:40 <Azhrei> need to implement a visibility priority scheme
06:12:55 <aloril> arf: yes.. each top level container can have different media
                        too
06:13:19 <aloril> arf: so at each zoom level you could use either detailed
                        tilemap or just handdrawn overview map even
06:13:37 <arf> or text description...
06:13:49 <aloril> arf: server sends things into certain accuraty, client then
                        uses what it can
06:14:22 <arf> crucial point is that server must send everything relevant to be
                        interacted with
06:14:28 <DragonM> Hrm.  Conceivable.
06:14:40 <DragonM> Not conceivable, arf.
06:14:54 <DragonM> Average available bandwidth in the US is still a 28.8 modem.
06:15:01 <DragonM> Average bandwidth connecting to an overseas server is even
                        less.
06:15:13 <DragonM> Sending everything relevant would clobber the link.
06:15:21 <DragonM> Correction.
06:15:24 <DragonM> Misinterpreted that.
06:15:36 <DragonM> Sending everything that references a given object, for any
                        client, would be bad.
06:15:51 <DragonM> Sending ONLY the specific description that references a
                        given object is the only way to go.
06:15:59 <DragonM> And the text guy will be able to get away with a 2400 baud. 
                        :)
06:16:03 <arf> er, it's like the difference between XML and CSS: one is pure
                        structure, one is pure style
06:16:13 <Laurel> DragonM: you mean media?
06:16:16 <aloril> arf: good example
06:16:21 <DragonM> Pretty much.
06:16:31 <DragonM> I got confused.  :)
06:16:36 <arf> game server deals in structure, client talks separately to media
                        server for style
06:16:47 <Laurel> DragonM: yeah, that's what the media server does...
06:16:55 <DragonM> Very difficult to differentiate.
06:17:00 <Azhrei> ok, here is a big example that causes most of our problems..:
06:17:03 <Azhrei> If we have a road that doubles back on itself on a
                        switchback, ie constantly rising, and on the lower portion there is a
                        cave entracne ie:
06:17:04 <Azhrei> rrrrrrrrrr
06:17:04 <Azhrei>                  rr
06:17:04 <Azhrei> rrrrCrrrrr
06:17:04 <Azhrei> where the c is an entracne...
06:17:06 <Azhrei> how can this situation be described best?
06:17:07 <Azhrei> and what heppnes when yo go into cave?
06:17:11 <Azhrei> do oyu "jump" to new map area, or if 3d based it could
                        acutally be under the upper part of the raod and the mountain?
06:17:44 <DragonM> If 3D, you're going to be actually under some surface that
                        another player can be walking on.
06:17:55 <aloril> meaning part:
06:18:00 <DragonM> Your own client wil not be seeing that data, because it's
                        not relevant, but it will be there.
06:18:17 <DragonM> There must be no jump to a new map area, or your
                        terrain-modifying requirement goes splat.
06:18:18 <aloril> whole_map==[road,plain,cave]
06:18:32 <Azhrei> dragonM:good point
06:18:51 <aloril> road:line==....,contains=[height data areas partitioned
                        suitably]
06:18:53 <DragonM> If somebody is playing as a dwarf, merrily tunneling along
                        through granite, and he hits the surface, a new entrance is created.
06:19:12 <DragonM> If you just jumped between maps, you just created a new map
                        portal on the fly.  Which is going to give the server fits.
06:19:20 <aloril> plain:area=='limiting polygon', contains=[-"-]
06:19:39 <Azhrei> I think that there are ways to show suffecient of the 3D data
                        in a 2D interface to work...
06:19:44 <DragonM> If you just cast a ridiculously powerful spell, caused a
                        rift in the earth to appear that happens to overlay a dungeon,
                        literally thousands of new portals will be created.
06:19:46 <aloril> (+ of course all attributes about: this is road, this is
                        grassy area, etc.. (probably inherited so most of time not sent over
                        wire)
06:20:00 <DragonM> By the time you do that, your separate map area concept is
                        junked up.
06:20:27 <arf> sorry ii didnt catch what aloril is saying
06:20:48 <DragonM> Aloril has a tendency to leave out words.  :P
06:20:56 <DragonM> 0.
06:20:59 <DragonM> .
06:21:05 <DragonM> Cat...
06:21:31 <aloril> DragonM: hmm..
06:21:45 <DragonM> I think you can too, and I think you can even manage the
                        ROAM dynamic loading and unloading.
06:21:52 <DragonM> Although that'll put a strain on the artists.
06:22:07  DragonM  rereads aloril's cryptic shorthand yet again.
06:22:33  DragonM  still isn't following that.
06:22:41  aloril  starts pondering media for highly dynamic word
06:22:54 <aloril> I guess media server needs to generate it then on the fly?
06:22:59 <DragonM> Heh.  Media for a highly dynamic 3D world is relatively
                        easy.  TExtures.  :)
06:23:18 <aloril> handmade 2D tile maps are much harder to make on the fly ;-)
06:23:20 <Laurel> hm.. there are a lot of tradeoffs here... and many seem to
                        depend on the specifics of a particular gameworld.
06:23:22 <DragonM> Some set of textures will be sufficient to represent
                        everything, eventually.
06:23:36 <DragonM> 2D tiles generated by code?  Not bloody likely.
06:24:06 <arf> Laurel, are you thinking of virtual spaces like the teaching
                        game?
06:24:59  DragonM  contemplates.
06:25:17 <Laurel> no, actually, but that too... depends on a lot of things,
                        like how dynamic the world is, how realistic, etc...
06:25:19 <DragonM> Doing all three clients is feasible.
06:25:28 <DragonM> Whether or not the experiences will be comparable remains to
                        be seen.
06:25:37 <Azhrei> Draongm I get the sense that you wish to make a 3d model of
                        the entire visible section. The thing is for objects ie characters,
                        and other things, you just have a descriptor, ie man#4 and get the
                        info elsewhere, but for terrain you want to pass actual 3d info for
                        it...
06:25:52 <DragonM> I think a text player would be at a severe disadvantage in a
                        realtime world.
06:26:14 <Azhrei> dragonm, course you could script actions and stuff in and do
                        things much much faster
06:26:21 <DragonM> Possibly.
06:26:25 <DragonM> Not my department.  :)
06:26:59 ** dmitryd has quit (dmitryd has no reason)
06:27:00 <DragonM> I think for terrain, if you want it deformable, you're going
                        to have do something outside of passing a descriptor, yes.
06:27:05 <aloril> DragonM: yes.. but we provide meaning and let text/2D clients
                        to find innovative solutions
06:27:11 <Azhrei> so a big question in miy mind is how to "bojectify" terrain
                        data"
06:27:36 <arf> let me get confirmation of one point: in order to support
                        multiple client representations, the map meaning/structure MUST be
                        entirely indedpendent of its appearance
06:27:40 <Azhrei> s/bojectify/objectify
06:27:44 <DragonM> Converting terrain data into something the concept of the
                        media server can handle, at the limit of 3D modeling, I don't think
                        is possible.
06:28:01 <DragonM> I don't think so, arf.
06:28:09 <DragonM> In fact, I don't think that's physically possible.
06:28:18 <DragonM> A map is all about specifying appearance.
06:28:24 <DragonM> How do you divorce the two?
06:28:32 <Azhrei> why not, couldn't we just define height at the edges of some
                        granular tiel size, and then let the client/media server decide how
                        to handle the inbetween space?
06:28:43 <arf> no a map is a mere graph of relations between objects
06:28:52 <Azhrei> hmmm political maps vs geographical maps, one has little to
                        do with appearance
06:28:55 <arf> graph in the mathematical sense
06:29:25 <Azhrei> arf: that is an extremely discontinous sense. with multiple
                        objects connected to each others via paths
06:29:41 <DragonM> A terrain map is a mathematical graph if extraordinarily
                        high order of nodes...
06:29:48 <DragonM> of
06:29:56 <arf> hmm, so how would you characterise the meaning of a map?
06:30:02 <Azhrei> the problem is that a terrain map is inherently continous,
                        this it isn't liek arelations of a bunch of terrain tile objects
06:30:27 <DragonM> By map, I mean terrain, mostly.
06:30:43  Azhrei  has been assuming that as the meaning of map for our
                        conversation
06:31:07 ** BludSport has quit (Leaving)
06:31:16 <DragonM> Buildings sitting on top of that terrain, if small enough in
                        terms of the granularity of the terrain, can be represented as a tag.
                         Larger structures I would think would go right into the terrain
                        data.
06:31:29 <Azhrei> are there other major sticking points in map description for
                        interclient work besides terrain??
06:31:59 <Sal> Azhrei, yep... structures
06:32:02 <arf> if terrain can be tunneled thru, then it isn't an atomic
                        continuous object.
06:32:15 <DragonM> Atomic?
06:32:32  Azhrei  doesn't think continous means atomic
06:32:40 <Azhrei>  or rather requres it
06:32:43 <DragonM> The only time I use atomic is when I'm talking about system
                        calls and threads.  :)
06:33:09 <Azhrei> I feel that sending height data across the wire is mixing 3d
                        data with map info
06:33:39 <arf> but height is important to all clients only if it is relevant to
                        interaction.
06:33:43 <Azhrei> which ought to be seperate somehow
06:34:07 <DragonM> And height is relevant to interaction, in enough cases that
                        it must not be discarded.
06:34:33 <Azhrei> very true... I don't wish to discard it.
06:34:54  DragonM  scrunches up his nose and blerfs.
06:34:55 <DragonM> Hmmmmm.
06:35:00 <arf> height is just an arbitrary object attribute, and it only means
                        something relative to another object and reference plane.
06:35:16 <Azhrei> yeah really :) I feel like it is just at the tip of my
                        tounge, but I cna't spit it out ;)
06:35:33 <DragonM> Height is an arbitrary object attribute for objects, but it
                        has another meaning entirely to terrain.
06:35:35 <Azhrei> arf that is a good point
06:35:38 <aloril> Azhrei: I think height data is essential part of meaning
06:36:13 <Sal> aloril: but streaming voxel height data to text clients seems
                        overkill doesn't it?
06:36:16 <Azhrei> I agree, but the difference is that a height field for
                        terrain is a very high detail concept, different then saying a cup is
                        at 4ft form teh base plain
06:36:22 <aloril> but how it looks or small granularity is not important for
                        meaning ;-)
06:36:35  aloril  floods
06:36:42 <aloril> road_curve={parents=['road'],
06:36:42 <aloril>                          line='polyline mostly following center of road',
06:36:42 <aloril>                          portals=['portal2cave']
06:36:42 <aloril>                          contains=['grid1','grid2','grid3']}
06:36:42 <aloril> plain4={parents=['grassy_plain'],
06:36:42 <aloril>                 border='polygon describing border',
06:36:42 <aloril>                 contains=['grid4','grid5']}
06:36:42 <aloril> mountain1={parents=['mountain'],
06:36:42 <aloril>                         grid='grid data using big granularity'
06:36:42 <aloril>                   
                        contains=['cave13','mountain_area1','mountain_area2',....]}
06:36:42 <aloril> cave13={parents=['cave'],
06:36:42 <aloril>                 volume='mesh describing what space it fills',
06:36:43 <aloril>                 portals=['portal2road_curve']
06:36:43 <aloril>                 contains=['floor3','wall6',...]}
06:36:43 <aloril> portal2cave={parents=['open_closed_area_portal'],
06:36:43 <aloril>                           point='center point',
06:36:43 <aloril>                           area='polygon describing whole area'}
06:36:46 <Azhrei> that is my point, so the qusetion is how to deal wiht
                        granularity?
06:36:51  Sal  drowns
06:37:01 ** Peregrine has quit (Leaving)
06:37:18 <aloril> or something like that
06:37:28 <arf> ugh.  we need to present some points of view via whitepapers.
                        sorry, i can't deal with that in irc
06:37:39 <arf> :)
06:37:47 <aloril> note that text client problems are in many ways similar to
                        what AI clients have
06:38:10 <aloril> well.. something like above is here too:
06:38:15 <Azhrei> aloril, that is actually pretty good, and of course very
                        close to what you and jamie came up with before :)
06:39:02 <aloril> we need right now two things:
06:39:15 <aloril> editr that can show several 2D tilemaps at once
06:39:23 <aloril> s/editr/editor/
06:39:46 <aloril> (xclient can show several .3ds files at once, so temporary 3D
                        media solution is there)
06:39:55 <aloril> and how to link above to media
06:40:41 <aloril> ftp://ftp.worldforge.org/worldforge/users/aloril/atlas/devel/
                        for .def files
06:40:54 <aloril> (and + index.html for .html version)
06:41:19 <DragonM> I actually followed that for the first time, arf.
06:41:21 <aloril> (it doesn´t talk about volume thingies and neither talks
                        about portals)
06:41:57 <Azhrei> true... it would be nice to describe the ultimate hights of
                        these items ie the cave, the mnt etc..
06:42:10  DragonM  thinks.
06:42:14  DragonM  strains something.
06:42:15 <DragonM> Ouch.
06:42:22 <Azhrei> so you use a polygon to describe the base of a mountain and
                        then say how high, then let the lcient deal withj it from there??
06:42:26  Laurel  thinks about representing stalactites and stalagmites.
06:42:34  Azhrei  thinks small mountains????
06:42:38  Laurel  runs away.
06:42:48 <Azhrei> thinks base height info and then height info
06:43:02 <aloril> Azhrei: that mountain object tells only it very roughly
06:43:27 <DragonM> That definitely cuts down on the data load tremendously.
06:43:28 <aloril> Azhrei: for details you see each mountain_areaX ...
06:43:34 <aloril> (like that cave13)
06:43:39 <DragonM> But the price you pay for that is increased genericism.
06:43:55 <DragonM> Every third mountain in a range looks identical.  :)
06:44:03 <aloril> so when you see mountain very far away you only get that
                        toplevel object
06:44:06 <Azhrei> aloril yes, That makes sense
06:44:18 <Azhrei> Dragonm, only if oyu don't do some kind of random
                        generation...
06:44:22 <Azhrei> in the client end I mean
06:44:25 <aloril> when you come nearer you get areas
06:44:25 <arf> i see the point as, what can the client DO with the mountain, or
                        the stalactite?  only those attributes are critical.  all others must
                        be optional
06:44:36 <DragonM> Randomly generated graphics look like what they are:
                        randomly generated.
06:44:37 <Azhrei> aloril that makes much sense
06:44:39 <aloril> and then more closely you get sub area grids
06:45:04 <DragonM> Look at a mountain range, look away, look at it again, it
                        changes?
06:45:11 <aloril> and then most accurate grids when you are there road maybe
                        100-500m away
06:45:21 <Azhrei> ok, how well does this handle on the fly manipulation IE I
                        split a casaam down the length of a land viea a huge earthquake
                        speelll?
06:45:38 <DragonM> casm....
06:45:43  calil has quit (reboot will be back so if everyone just was quiet
                        till im back ok?)
06:45:44 <arf> chasm
06:45:57 <aloril> server needs to understand some meaning:
06:46:03 <DragonM> Yeah, that's it.  I knew that didn't look right.  :)
06:46:05 <Azhrei> Dragonm: you could randomly generate and save as long as
                        server doesn't let you know about changes
06:46:28 <Azhrei> or you could have base that is then randomly modified to make
                        it look differently
06:46:37 <DragonM> Thereby creating a rapidly growing "cache" on the client
                        side of what the world looks like, which is unique for every user.
06:46:45 <aloril> you do modify mountain and all relevant areas (likely destroy
                        them and create new ones instead)
06:46:50 <Azhrei> so everyone sees the real world differently
06:46:59 <Azhrei> aloril ok...
06:47:07 <DragonM> People would tell each other " head for the mountain with
                        the grey blotch on the left shoulder" and the other guy would say,
                        WHAT mountain with a grey blotch?
06:47:12 <aloril> DragonM: exactly: caching is very important and atlas even
                        has stamp attribute:
06:47:38 <aloril> if things are cached and say... there are few new plants and
                        one people:
06:47:50 <Azhrei> dragonm, some things might be visible form a distance, like a
                        big tree, or a big cave entrance... these would be there despite
                        random generation...
06:47:51 <aloril> you can even fly over mountain high speed: server tells you
06:47:57 <DragonM> People expect terrain to be identical to each other.
06:48:09 <aloril> (after client ask: what changes after this?)
06:48:15 <Sal> Aloril: how would the editor figure out the heirarchy of
                        containers?
06:48:16 <DragonM> Er, that was tangled, but you get the idea.
06:48:22 <aloril> these parts have changed
06:48:27 <Azhrei> dragonm, that is a client issue... not really an issue for
                        the format though
06:48:29 <aloril> and then tells what new objects there was
06:48:58 * calil (~andla028@h35n1fls20o974.telia.com) has joined #forge
06:49:01 <Azhrei> terrain will be different between a2d vs 3d client already,
                        so your obejction isn't to big a deal...
06:49:02 <Sal> ie if the artists lays a bunch of tiles, some are grass, and
                        some are road.... the editor would need to know how to extract the
                        'road' from the grass somehow
06:49:16 <DragonM> Erm.  True.
06:49:36 <brenda> OH cool, calil!
06:49:38 <aloril> DragonM: well.. that big gray blob would be part of whole
                        mountain grid
06:49:53 <aloril> (ie that 100m x 100m granularity one or something like that)
06:49:53 <DragonM> If it was significant, I suppose it would be.
06:50:07 <Azhrei> or if it was a big bolder.... it would show up at some level
                        of detail...
06:50:08 <arf> objects must support the capabilities: split, merge, transform,
                        translate, expose-capabilities(granularity)
06:50:39 <aloril> Sal: editor needs to treat road as separate object from plain
06:50:48 <Azhrei> so basically, a bolder could be an outer container, inside of
                        which is surface data, color etc.. correct??
06:50:59  DragonM  gurgles.
06:51:04 <aloril> Sal: and I think there will be several views: meaning view
                        and then 2D/3D/text/whatever ones
06:51:16 <Azhrei> far enough away all you get is outer impression of boulder,
                        as you get closer you COULD ask to see the surface data...
06:51:36 <DragonM> Hrm.  Wonder if ROAM data could be encapsulated that way.
06:51:38 <aloril> Azhrei: or server tells it
06:51:40 <DragonM> Might be possible.
06:52:08 <Azhrei> aloril I think that this system makes sense... level of
                        detail encapsilation allows for limited clients to only get so
                        detailed,...
06:52:24 <Azhrei> BRB gotta tuck my fiance into bead ;)
06:52:31 <aloril> arf: see atlas operations: combine, divide, create, destroy,
                        set
06:52:37 <arf> :)
06:53:35 <aloril> Sal: so instead of placing lots of tiles map creator does
                        this:
06:53:55 <aloril> hmm.. lets draw road polyline here using road tool
06:54:04 <aloril> and lets fill area here with plain tool
06:54:15 <aloril> hmm.. 2D view is needs some fixing
06:54:40 <aloril> creator changes some tiles and fix locations
06:54:45 <aloril> goes back to meaning map
06:54:50 <aloril> adds mountain
06:54:51 <aloril> etc..
06:54:53 <DragonM> To misquote Mr. T, I pity the foo' who has to implement the
                        editor...
06:55:09 <arf> so each object has its own editor interface...
06:55:10 <Sal> hmm, ok so the artist adds a bunch of mountains with a mountain
                        tool...
06:55:19 <aloril> DragonM: well... initially we start with this:
06:55:21  arf  thanks DragonM for his pity :)
06:55:27 <aloril> areas + point objects
06:55:28 <Laurel> would be nice if the editor could pretend to be a server, so
                        you could look at it with the real clients..
06:55:35 <aloril> then later add line tools:
06:55:37 <DragonM> You're welcome, arf.  :)
06:55:41 <Sal> but how do the mountains get grouped into a 'mountain range' the
                        artists has to create those groupings?
06:55:42 <aloril> area tool:
06:56:00 * snarf has quit (Ping timeout)
06:56:05 * snarf (~giles@raj.phys.sfu.ca) has joined #forge
06:56:05 <aloril> basically like any image manipulation program:
06:56:11 <aloril> select palette (ie ground type)
06:56:15 <aloril> then draw area
06:56:23 <Sal> what if the mountains are spread out with objects in between
                        them?  does everything get added into the 'mountina range' container?
06:56:26 <aloril> then you go to 'pixel' view (2D tiles) and adjust them
06:56:41 <aloril> Sal: I guess so
06:56:58 <DragonM> There would have to be some media correspondence, I suppose.
06:56:59 <aloril> well... when creator has done some part it can do this:
06:57:08 <DragonM> Which 2D tileset approximates which set of textures.
06:57:13 <aloril> this whole map is 'mountainy area foo'
06:57:40 <aloril> DragonM: simple meaning map editor should be hard to do
06:58:01 <aloril> DragonM: but making 'generate good looking tilemap from
                        meaning map' is hard ;-)
06:58:16 <aloril> but we don't need that button now
06:58:21 * snarf has quit (EOF From client)
06:58:36 <DragonM> Indeed.
06:58:42  snarf (~giles@raj.phys.sfu.ca) has joined #forge
06:58:45 <brenda> Welcome to #forge, snarf
06:58:47 <arf> are mountains each objects, connected in a kind of "next-to"
                        relationship graph?  does each mountain "know" what it is next-to  or
                        is there a matrix object  that specifies that externally?
06:59:02 <aloril> arf: initially it's enough if each object type has tool:
                        point, line, area and volume (and currently we need only point and
                        area tools)
06:59:06 <DragonM> SO basically the editor has to operate at the full 3D level,
                        using full-on ROAM granularity, encapsulate into objects, then
                        downsample to 2D and text.
06:59:16  DragonM  reiterates: I pity the foo'.  :)
06:59:23 *** rillian has quit (off home)
06:59:43 <Laurel> text isn't really downsampling either. it's like
                        across-sampling..
06:59:54 <aloril> mountain_range={contains=["mountain1","mountain2","valley4"]}
07:00:12 <DragonM> Well true.  But you know what I meant, Laurel.  :P
07:00:29 <arf> ok. so there will be a way to "place mountain_range" 
07:00:31 <aloril> DragonM: eventually yes, but for now only need to handle few
                        levels
07:00:48 <Laurel> yep...lots of fun :)
07:01:26 <DragonM> Oooh.  Implementing this thing in a "for now" kind of scheme
                        could have severe repurcussions later.
07:01:49 <DragonM> You do realize you're talking about something of a
                        complexity no commercial project has ever even attempted, let alone
                        pulled off.  :)
07:02:01 <aloril> DragonM: not for format... but editor might need rewrite ;-)
07:02:11 <aloril> DragonM: well: this is what I'm hoping:
07:02:19 <DragonM> Editor could get itself badly mangled.  :)
07:02:23 <arf> so map editor (and new map) should start with a single object:
                        "root"?
07:02:24 <aloril> define good meaning map format
07:02:30 <DragonM> Format would have to be fully flexible and set in stone.
07:02:37 <arf> xml
07:02:38 <aloril> make some maps using above format
07:02:46 <DragonM> If that's not an oxymoron...
07:02:49 ** Drew has quit (Ping timeout)
07:03:15 <aloril> arf: root is abstract object, more like:
07:03:18 <aloril> "world"
07:03:20 <arf> DragonM, we are not constrained like commercial projects
07:03:34 <DragonM> I know.  I'm the guy who told the Crossfire project that,
                        arf.  :)
07:03:48 <DragonM> Ain't no budget constraints in an Open Source, Free software
                        project.  :)
07:04:13 <aloril> DragonM: my plan is this:
07:04:25 <aloril> DragonM: include meaning in maps and everywhere else
07:04:38 <aloril> DragonM: that allows later to make much* more intelligent
                        tools much easier
07:04:47 <Laurel> what would be nice is a "map handling" api that does
                        everything we could ever need, and an implementation of that api that
                        handles a subset of it...
07:05:08 <aloril> DragonM: and thus we need to have meaning from the beginning
07:05:10 <arf> like libCOAL?
07:05:28 <aloril> DragonM: adding meaning to DXF lines/polygons/etc.. is much
                        harder after the fact ;-)
07:05:38 <DragonM> Sounds quite reasonable, aloril.  I second the motion. 
                        Write it up.  Whitepaper, followed by design document.  :)
07:05:41 <arf> aloril, indeed
07:06:16 <Laurel> afr: yes, soemthing like that. except not only 2d and 3d.
07:06:26 <arf> hmm, yes
07:06:33 <DragonM> Include a glossary of terms in the whitepaper, which you can
                        migrate to the design document.
07:07:05 <DragonM> Describe in general the concept in white paper, with a few
                        examples.  Some diagramatic concept art would be good.
07:07:12 <aloril> of course to have it simple too for simple usage... 
07:07:29 <aloril> here is very short white paper ;-) :
                        ftp://ftp.worldforge.org/worldforge/users/aloril/atlas/devel/map.def
07:07:32 <DragonM> Then describe in excrutiating detail ever facet of it in the
                        design document, complete with a busload examples.
07:07:33 <aloril> see '#' parts
07:07:39 <Sal> hmm, Al... I think your format is perfect for text clients, but
                        for graphical clients more specific data is needed...
07:08:00 <aloril> Sal: thats why there is media
07:08:40 <DragonM> Yeah.  That's where the media server/repository comes in. 
                        To as great a level of detail as artists are capable of taking it, I
                        think.
07:08:56 <arf> Sal+aloril, some "descriptive" attributes are relevant to play,
                        so they shuld be added if not there
07:09:00 <aloril> server needs only height grid or volume mesh and type of
                        terrain to control movement speed
07:09:08 ** calil has quit (Ping timeout)
07:09:13 <Sal> the media parts is what is badly needed though.  We need a
                        media-independant way to describe those parts...
07:09:21 <aloril> but everything that is only for chrome, should be part of
                        media
07:09:26 <DragonM> Media server can start off with generic "grass" texture that
                        map format pulls in for 3D, a generic "grass" tileset that map spec
                        pulls in for 2D clients, and a generic grass text description.
07:09:29 <Sal> ie lets say I wanted to make a simple map, of a hill, with a
                        path going across it.
07:09:35 <DragonM> And so on, out to the minimum extent of a world.
07:09:41 <aloril> Sal: so how does 3D talks go currently? has any good format
                        found?
07:09:45 <bryce> aloril, that is not a whitepaper
07:09:54 <DragonM> Bryce lurks.  :)
07:10:03  bryce  grins
07:10:06 * aloril  smiles at bryce
07:10:10 <Sal> a map format that says 'world-&gt;hill-&gt;road' doest help graphical
                        clients much :)
07:10:16  DragonM  attacks Bryce with a can of silly string.
07:10:29 <aloril> Sal: road->road_blocks
07:10:34 <bryce> aloril, but it looks like you could turn it into a very good
                        whitepaper
07:10:38 <aloril> road_blocks->grid_data
07:10:45  bryce  relurkifies
07:11:04 <DragonM> Oh geeze.  No, that's not a whitepaper.  :)
07:11:22 <arf> aloril, what is grid_data in game relevance? i.e., how would a
                        text-client interact with it?
07:11:23 <Sal> Al, but that's still useless :)
07:11:28  aloril  smiles to DragonM too ;-)
07:11:55 <aloril> arf: well.. text client might tell something like: there is
                        slope upwards in front of you
07:12:12 <Sal> I need a grid of height values and exture information to render
                        the hill in xclient, and 2d clients need to create tile data from
                        something
07:12:16 <aloril> Sal: for 3D yes... and thus we need 3D format
07:12:28 <aloril> and 2D format for 2D client
07:12:30 <Sal> we cant have 2d artists make a hill, then 3d clients make a hill
                        in speerate tools,
07:13:01 <aloril> Sal: they would use common meaning map and add chrome for it
07:13:19 <arf> secondly, are there attributes to "road_blocks" such as "gravel,
                        wet, rough, soft, hot"?
07:13:22 <Laurel> hm, i suppose you mean the client would tell the media server
                        "give me this hill", and it would return a height map or whatever..?
07:13:29 <aloril> (hopefully using same editor that has meaning/2D/3D views)
07:14:08 <aloril> arf: yes (some of those would be part of road itself too)
07:14:18 <aloril> (like road name if it has one)
07:14:43 <DragonM> Yes.  In 3D, the client would say give me this hill, and the
                        media server would kick back ROAM data.
07:14:50 <aloril> one unresolved question:
07:15:00 <DragonM> In 2D, the media server would kick back tile data.
07:15:03 <aloril> meaning map -> media linkage
07:15:12 <DragonM> In text, the media server would kick back a paragraph.  :)
07:15:40 <aloril> 1) every object has mediaid
07:15:50 <arf> so in fact we are talking about an SGML-docbook-like structure
                        in which every object has some meaning
07:16:07 <aloril> or 2) every object has list_of_media_relevant_attributes
07:16:54 <aloril> or 3) server only tells media server "file:"
                        "atlas://media.game.net" "http://www.media.game.net" etc...
07:17:18 <aloril> and client itself ask media server using object id
07:17:18 * sferro (~sferro@ppp-pm03-dy-7.opr.oakland.edu) has joined #forge
07:17:20 <brenda> Hi, I'm brenda, WorldForge's secretary bot
07:17:33 <sferro> :P sorry, dropped
07:17:58 <aloril> arf: yes... every object has some meaning, mostly inherited
                        from it's parent
07:18:25 <arf> but then the most modular approach is to use a separate
                        stylesheet language/representation for the media-relevant-attributes
07:18:38 <aloril> arf: so option 3 is best?
07:18:47 <arf> i.e., not keep them in the objects themselves
07:19:06 <DragonM> Right it up, aloril.  Expand map.def into a complete
                        description.
07:19:08 <arf> i guess that's my question
07:19:11 <DragonM> And try not to leave out words.  :)
07:19:15 <aloril> (option 3 could be "#M" too is same server handles it ;-)
07:19:18  DragonM  sighs.
07:19:24 <DragonM> I should criticize his English...
07:19:26 <DragonM> Write it up, even.
07:19:29 <DragonM> Yeah, I can spell, really.
07:20:11 <arf> what are the consequences of a separate media_representation
                        stream?
07:20:28 <arf> is that what we intended with the media-server?
07:20:47  DragonM  didn't intend anything with the media server.
07:20:58  DragonM  thought it was an alien concept, first time he heard the
                        phrase.  :)
07:21:00 <Azhrei> So is there a consensus that the system described by aloril
                        is feasable? can we take an informal vote of all those reading??
07:21:04  arf  wasn't there when they discussed it
07:21:20 <arf> we won't know if its feasible until we read the whitepaper :)
07:21:25 <sferro> ok, Al... heres my problem...
07:22:03  Sal has quit (Connection timed out)
07:22:19 <sferro> lets say there's some terrain, a simple small area with some
                        hills in it
07:22:22  sferro is now known as Sal
07:23:17 <Sal> lets say this big chunk of terrain is the mapfile. really just a
                        piece of land with some variations in its height
07:23:45 <Sal> so the mapfile would relaly just be world->chunk_of_land ?
07:23:59 <Sal> and then the server sends land.3ds to 3d clients,
07:24:07 <Sal> and land.2d to 2d clients, correct?
07:24:21 <Sal> (when they ask to view chunk_of_land)
07:24:27 <Azhrei> wouldn't it be world->chunk_of_land->{hill1, hill2, hill3}
07:24:30 <aloril> no,
                        world->chunk_of_land->[smaller_chunk1,smaller_chunk2,....,smaller_chunkX] (depends how many is needed)
07:25:03 <aloril> world media: handdrawn picture of whole world
07:25:15  Drew (DrewNumber@cae31-203-019.sc.rr.com) has joined #forge
07:25:19 <brenda> hi Drew
07:25:19 <Azhrei> it seems to me that this apporach works well, but editor is
                        of extreme importance....
07:25:24 <aloril> big land: separate tile map using 0.1 or 0.01 zoom factor
07:25:28 <aloril> each piece: normal tiles
07:25:31 <aloril> (same for 3D)
07:25:43  bryce has quit (Ping timeout)
07:25:58 <DragonM> Oh yah.  Attempting to create a world based on that spec by
                        hand would be a masochist's dream.  :P
07:26:18 <Azhrei> Aloril, If you want soem help writing up a white paper on
                        this, I'd be willing to try and coauthor it with you...
07:26:22 <aloril> DragonM: hmm.. could code world though ;-)
07:26:30 * calil (andreas@h167n3fls20o974.telia.com) has joined #forge
07:26:31 <brenda> All rise the honorable Judge calil presiding..  :)
07:26:33 <aloril> Azhrei: that would be really cool!!
07:26:39 <Azhrei> dragonm, hmm am I a masochist???
07:27:00 <DragonM> Only if you don't use the editor, Azhrei.  :)
07:27:04 <DragonM> I agree with arf.
07:27:10 <aloril> DragonM: what about map library/editor written in high level
                        pseudo language?
07:27:10 <Azhrei> OK, well I have the full log of this discussion, as well as
                        the other map.def files etc...
07:27:13 <DragonM> Write it up.  Completely.
07:27:41 <arf> yes, and we can comment after each draft, right DragonM?
07:27:44 <DragonM> Don't waste your time on a pseudo language other than
                        English.  :)
07:27:51 <DragonM> Oh boy can we comment, arf.  :)
07:27:51 <Azhrei> Dragonm: so it is said so it shal be written... We'll see
                        what we can do...
07:28:02 <DragonM> We want full blown whitepaper.
07:28:12  Azhrei  fears free comment, our design documents always went like 70
                        rounds :(
07:28:25 <aloril> Azhrei: see world section of www.worldforge.org
07:28:28 <DragonM> If we don't see any major flaws with the whole thing laid
                        out, it's time for full blown design document.
07:28:44 <DragonM> If we don't see any problem with the design, go for it.  :)
07:28:45 <Laurel> hm, this'll be the first real whitepaper written...
07:28:52  DragonM  applauds your bravery.  :)
07:28:55 <Sal> Aloril, I'm still confused :)  Azhrei: some docs would be very
                        nice
07:28:59 <aloril> and there are some map meetings (though most of those content
                        was rehashed here: we got new things talked too)
07:29:13 * Chord has quit (Connection timed out)
07:29:19 <DragonM> See, Sal is confused.  Write it up, aloril.  :)
07:29:33 <arf> Sal, what is confusing you?
07:29:34 <Azhrei> I have already written some about atlas in general...
07:29:39 <aloril> oh... it's all so clear in my head ;-)
07:29:58 <Sal> arf, I dont think it will work for graphical clients
07:29:59 <aloril> http://www.worldforge.org/website/worlds/meetings/
07:30:01 <DragonM> I'll even volunteer to polish your English, since either
                        it's not your native language or you're so ghetto it's absurd.  :)
07:30:05 <Sal> but for text clients it would be perfect...
07:30:11 <aloril> 2000-03-
07:30:28 <aloril> Sal: why not for graphical ones?
07:30:46 <DragonM> See, as I understand what he's said, it could work for
                        graphical clients.
07:30:49 <aloril> can't graphical ones take all those bottom 'chunk1',
                        'chunk2', etc.. 
07:30:51 <arf> Sal, what will not work? i'm wondering if it's like the
                        difference between wysiwyg and non-wysiwyg editing
07:30:54 <DragonM> Whitepaper should have sufficient detail to explain how to
                        sal.
07:31:00 <aloril> fetch media for each and then combine it to one big area?
07:31:03 <DragonM> That's the first litmus test.  It is so ordered.  :)
07:31:48 <aloril> ok: about media:
07:31:59 <Sal> well... Al, it would have to be extended to incorporate height
                        data somehow, efficiently
07:32:00 <DragonM> And aloril, write it formally.  Capitalize your sentences. 
                        :P
07:32:17 <aloril> when you tell media server object id (and possible it's
                        parent if no media for that object is available like might usually be
                        case for humans)
07:32:39 <aloril> Sal: it does have height data
07:33:00 <DragonM> It doesn't have height data, but it does.  :)
07:33:05 <aloril> then media server gives you generic media info:
07:33:09 <DragonM> Height data is available on demand, as needed, depending on
                        client features.
07:33:15 <DragonM> And with the granularity needed, as well.
07:33:20 <Sal> Al: could you make a sample mapfile real quick that represents a
                        hill or something?
07:33:49 <arf> btw, i volunteer to proofread/edit the paper, if needed.
07:33:51 <Sal> in a way that 2d and 3d clients would understand....
07:34:07 <aloril> ftp://ftp.worldforge.org/worldforge/users/aloril/atlas/devel/map.html or
07:34:07 <DragonM> I already did arf, but you can have it.  His English is so
                        Euro it hurts.  :)
07:34:24 <DragonM> That .fi top level domain is not just a fetish.  :)
07:34:26 <aloril> ftp://ftp.worldforge.org/worldforge/users/aloril/atlas/devel/agrilan_map.def
07:34:56 <aloril> arf: cool! (I'm not native English speaker)
07:35:19  DragonM  was copy editor for a .de author for a while.  I've done my
                        time.  :)
07:35:19 <arf> i'm used to working with non-english speakers. np.
07:35:22 <aloril> Sal: ahh.. that map doesn't have media objects
07:35:23 * bryce (~bryce@ppp231.neptune.net) has joined #forge
07:35:45 <Sal> ahh minor detail eh? :)
07:35:55 <aloril> Sal: it does have height though
07:36:01  calil  is away: im away  :)
07:36:04 <DragonM> All right, I'll say something got accomplished just as soon
                        as I see a whitepaper on the website.  :)
07:36:08 <Azhrei> I speak english as my first lang...
07:36:13 <DragonM> Until then, my contact just called to pester me.
07:36:19 <DragonM> It's time to do some paying work.
07:36:20  aloril  is currently talking about media 
07:36:30  aloril  restarts
07:36:45  DragonM  already understands how media integrates, so I think I'll
                        bow out now.
07:36:52 <brenda> Hi, I'm brenda, WorldForge's secretary bot
07:36:54  arf  waits for aloril to finish his POST
07:37:03 <aloril> client.send(object_id,media_server)
07:37:17 <aloril> media_server.send(generic_description_object)
07:37:17  DragonM  thinks you are all NUTS, aloril most of all.
07:37:20 <DragonM> And this is a good thing.  :)
07:37:50 <aloril>  contains: relevant_attributes_generally +
                        ids_for_each_type_of_media
07:38:46 <aloril> media_card: id, conditions_when_this_relevant,
                        actual_media_description
07:39:22 <Sal> ahh agrilan_map.def makes sense
07:39:23 <DragonM> That can be streamlined, but it'll do for illustrative
                        purposes.
07:39:24 <Sal> so:
07:39:30 <aloril> conditions_when_this_relevant: sex=male and (speed>5 or
                        state="running")
07:40:02 <aloril> actual_media_description: well.. somebody fill this up?
07:40:06 <aloril> ;-)
07:40:13 <DragonM> Heh.
07:40:28 <DragonM> Actual media description varies, depending on requirements,
                        of course.
07:40:44 <DragonM> However, I would use a different data exchange.
07:40:57 <aloril> examples of actual_media_description could be:
                        image="http://foo.media.org/dfjkg/kj/flower.png"
07:41:04 <Sal> grid_size:[1, 5]
07:41:06 <Sal>      grid_data:
07:41:06 <Sal>                    :list:
07:41:06 <Sal>                             :map:
07:41:06 <Sal>                                      height:1.38
07:41:06 <Sal>                    :list:
07:41:10 <Sal>                             :map:
07:41:12 <Sal>                                      height:1.36
07:41:20 <Sal> (excuse the spam)
07:41:23 <DragonM> And the media server would exist in two places.  It would
                        run on the client's local machine, and it would "out there"
                        somewhere.
07:41:32  aloril  nods to DragonM
07:41:33 <Sal> al: that's how terrain data is represented, correct?
07:41:40 <aloril> Sal: yes
07:41:56 <DragonM> Local server would be hit first for distributed and cached
                        media, and if what is desired is not found, the server "out there" is
                        consulted second.
07:42:00 <Sal> couldnt it get extremely large for say, 1000x1000 regions?
07:42:00 <Sal> maybe if we could do:
07:42:07 <Sal> grid_data = "some_media_id"
07:42:15 <aloril> Sal: it's retangular area, but it can leave holes or be
                        irregular: those areas are then empty
07:42:17 <Sal> and the media id could point to a voxel heightmap...
07:42:26 <DragonM> it would, Sal.
07:42:39 <DragonM> Or it would point to some arbitrary, "reasonable" sized
                        chunk of ROAM data.
07:42:55 <DragonM> Or it would point to a 2D tileset and an ordering of tiles
                        used.
07:43:06 <DragonM> Or it would point to a paragraph or sentence of descriptive
                        text.
07:43:12 <aloril> Sal: in binary encoding it would be basically height list
07:43:13 ** pse (~pse at 1Cust149.tnt16.long-beach.ca.da.uu.net) has joined
                        #forge
07:43:21  Sal  nods to Al
07:43:23 <DragonM> Except those aren't ORs.  it would point to all of those,
                        and what gets used by the client is the appropriate data.
07:43:34 <pse> Alright folks. I've found a perfectly good format for the 3d
                        client.
07:43:36 <Sal> binary would be more efficient for large areas :)
07:43:52 <DragonM> So if you have a client with a voxel engine in it, you would
                        be getting the appropriate voxel data for terrain.
07:43:53 <aloril> pse: just in time: we were pondering about media for 3D
                        client ;-)
07:43:56 <pse> And if we have masochistic coders, perhaps the 2d client. ;)
07:44:14 <DragonM> if you have a ROAM 3D client, you would be getting the
                        appropriate terrain data for ROAM.
07:44:20 <DragonM> Etc etc.
07:44:24 <Sal> it makes more sense now, Al.  I'm going to start a thread about
                        map formats on the MLs soon, I'll add yours in
07:44:30 <pse> aloril: genesis 3d format. The engine itself is free, but not
                        opensource. But the specs on their format are, and there are a couple
                        of converters from max and hash formats.
07:45:00 <Sal> pse: we looked at that already :)
07:45:03 * DragonM  does not appreciate genesis 3D, or Jet3D, or any of those.
07:45:08 <pse> Darn. Why not?
07:45:22 <DragonM> But clients aren't my specialty, so I'll shut up now.
07:45:54 <Sal> well its not a bad format for a 1st gen. 3d game... though the
                        quake 1/2 map formats could be used to the same result, and have free
                        tools available also
07:45:58 <pse> DragonM: Wait.. why don't you 'appreciate' genesis3d and
                        whatever?
07:46:02 * calil has quit (Ping timeout)
07:46:24  calil (andreas@h167n3fls20o974.telia.com) has joined #forge
07:46:26 <brenda> calil can I help you?
07:46:28 <pse> Sal: So. Um. Well, I guess I'll go hunt down some more formats
                        then. Although genesis 3d looked pretty good to me.
07:46:40 <pse> Sal: Any reason not to use it?
07:46:46 <DragonM> It's free, for now, but because it's not open source, it
                        can't be adjusted, and because it's not Free in RMS terms, licensing
                        for it could change at the drop of a hat.
07:46:58 <DragonM> Which could conceivably yank the rug out from a lot of hard
                        work.
07:47:45 <pse> DragonM: Umm. Well... as far as I can tell, there aren't really
                        any free 3d formats out there. Almost all of em belong to someone. ;)
07:47:54 <DragonM> I vote for CrystalSpace, for 3D engine, if not using an
                        in-house developed engine like the xclient apparently uses.
07:48:02 <Sal> pse, the 3d artists want something that supports bones/ik
                        animations, multiple materilas advanced surface properties (alpha
                        maps, bump maps, etc.)
07:48:15 <Sal> like .3ds .ase .obj do
07:48:35 <pse> Sal: genesis supports bones.
07:48:48 <DragonM> The WorldForge project allegedly has a plethora of talented
                        coders, so if CrystalSpace has some rough spots, WorldForge could
                        invest some energy into fixing them and extending it.
07:48:49 <aloril> DragonM: I think CrystalSpace and XClient plans to merge some
                        day
07:48:52 <Sal> the genesis character format does,
07:48:54 <chuck> DragonM: crystalspace is not a modeller
07:48:56  pse  is almost absolutely sure about this one. Unlike 3ds. :)
07:49:18 <pse> Sal: And.. as far as I can tell, me'n'garg are the only active
                        3d modellers. :)
07:49:19 <Sal> that is accomplished through a 3d studio export plugin though
07:49:42 <Sal> ie the only way to make bones genesis models is to use 3d
                        studio... which is very expensive...
07:49:46 <pse> Sal: Not exclusively.
07:49:52 <DragonM> No, it's a renderer.  Modeler is an artist-specific thing,
                        and I think attempting to specify a single modeller would encourage
                        rebellion.  :P
07:50:06 <pse> Sal: Hash can make a boned genesis model. And I can go look for
                        a converter if you like.
07:50:26 <Sal> Hash? is that a free modeller?
07:50:45 <DragonM> The native format for the game clients should be whatever
                        the renderer likes best.
07:50:53 <pse> Sal: No. Lemme think though...
07:50:56 <DragonM> I doubt that's 3D Studio.
07:51:02 <pse> Spatch -> Hash -> Genesis3d
07:51:09 <arf> if a format is free now, that same format will always be free,
                        we fork our own version of it and go from there for revisions.  this
                        is why we need a parallel 3d modelling tool development project.  we
                        can depend on the proprietary world continuing to change formats on
                        us forever.
07:51:10 <pse> That might work.
07:51:12  chuck  is not much on the free software philsophy of "fix it
                        yourself".  if something has unacceptably rough spots, it's just not
                        suitable.
07:51:15 <DragonM> So you convert.  No big deal.
07:51:24 <pse> DragonM: Very big deal.
07:51:41 <DragonM> arf has a point.
07:51:47 <DragonM> And just quintupled the amount of work.  :P
07:52:07 <pse> Just so you know, low res models tend to have intricate decals
                        and no bumpmaps, so I wouldn't look for something like .obj to use in
                        the engine. :)
07:52:18 <DragonM> I don't appreciate that either at times, chuck, but a
                        project as ambitious as WorldForge can afford that.
07:52:35 <chuck> i believe the opposite
07:52:44 <Sal> pse, why restrict our engine though?
07:52:52 <chuck> a project as ambitious as WF cannot be bothered to fix their
                        own tools
07:52:53 <Sal> xclient already supports bump and alpha maps,
07:53:01 <chuck> the tools shouldnt be broken in the first place
07:53:07 <Sal> and specular/opacity/diffuse material props,
07:53:09 <pse> Sal: Why expand when bump maps won't be noticed at all?
07:53:19 <pse> Sal: Those kinds of things are integrated into the final decals.
07:53:21  chuck  doesn't think CS is broken, it's just unproven and has no
                        real API
07:53:26 <DragonM> Is Eidetic perfect, chuck?
07:53:40 <pse> Sal: Efficiency and speed. Bump maps, alpha maps. Those are
                        going to kill your renderer, unless you're some super genius coder.
                        ;)
07:53:43 <DragonM> CS isn't so much broken as it is feature-incomplete.
07:53:52 <Sal> not really pse
07:53:59  chuck  watches his point just fly way over everyone's head.  is
                        quite used to that by now.
07:54:00 <Sal> ever see the matrox techdemo?
07:54:05 <pse> Anything more than a decal is overkill. There's a reason
                        low-poly models are designed the way they are.
07:54:14 <DragonM> I got the point just fine, chuck.
07:54:21 <DragonM> You ignored the rebuttal.
07:54:24 <arf> chuck, which tools are you saying are broken?
07:54:43 <pse> Sal: I was under the impression that we weren't going to require
                        an extremely high end system to run the client. :)
07:54:57 <chuck> none.  i'm taking issue with the philosophy that we should
                        ever take on using broken tools and fix it ourselves first
07:55:12 <Sal> oh, for xclient you will be able to use a low end 3d system BUT
07:55:15 <chuck> a quality product is one that's supported by the folks who
                        made it
07:55:21 <Sal> not at the sacrifice of the high end ones :)
07:55:28 <DragonM> And I say the philosophy arises because WorldForge does not
                        have funding, and hence, little choice in the matter.
07:55:39 <pse> Sal: Well, take a look at Q3 and UT... I'm pretty sure I don't
                        see any bumpmaps in the models.
07:55:43 <Sal> pse, check this out:
07:55:45 <Sal> http://www.wojo.com/sferro/g4demo/g400demo4.jpg
07:55:49 <chuck> there's plenty of choice out there in the opensource world too
07:55:56 <DragonM> In 3D engines?
07:56:04 <DragonM> News to me...
07:56:08 <Sal> we're going for that kind of quality... and its not possible
                        without maps,
07:56:14 <DragonM> I don't think Doom's engine counts.  :P
07:56:15 <Sal> and advanced material properties...
07:56:37 <aloril> Sal: about mim: we could add later mim like autogeneration to
                        it: I think it's extendable to MIM? (MIM probably needs changes to
                        handle height though)
07:56:44 <Sal> the (stump and water are bump mapped) and the trees are alpha
                        mapped
07:56:52 <chuck> there's mesa, there's CS, probably could turn up a few others
07:57:09 <Laurel> mesa is a 3d engine?
07:57:10 <pse> Sal: I'm not sure there's anything but decals on that image.
07:57:34 <arf> MESA is a OpenGL clone
07:57:36 <chuck> it's an implementation of a 3d api for which there are many
                        many wrappers
07:57:53 <pse> Sal: Image maps yes. Bump maps? Highly unlikely. Alpha maps,
                        probably.
07:57:55 <chuck> there's quake now
07:58:03 <Sal> its a shot from a realtime demo I took, pse.  The bump and alpha
                        maps make a huge difference :)
07:58:22 <pse> Sal: What's it look like without the alpha and bumps?
07:58:42 <pse> Sal: I can see the alpha, but no reason the bumps can't be
                        simulated in the image map.
07:58:59 <Sal> well the water ripples dont distort the reflection, and shadows
                        arent cast by the bump maps...
07:59:07 <pse> Sal: And you're insane. The g400 is the only thing powerful
                        enough for a realtime bumpmapping. :)
07:59:23 <Sal> and the trees would look like huge black opaque rectangels are
                        protruding out of them...
07:59:32 <Sal> other than that I guess it would be 'ok' :)
07:59:50 <pse> Sal: Without the bumpmaps? Uhh... why would the trees be opaque?
                        :)
07:59:57 <Sal> g4, and the geForce
07:59:58 <chuck> hm, the monoliths invade the forest
08:00:02 <Sal> pse, the trees are alpha mapped
08:00:10 <DragonM> Monoliths.
08:00:17 <pse> Sal: I only said bumpmapped. I know you can't do trees without
                        alpha. :)
08:00:24  DragonM  grabs for his club and begins the dance around the huge
                        black opaque rectangle.
08:00:38 <Sal> aloril: yep mim could be extended to incorporate this stuff
                        easily
08:00:40 <pse> Sal: And you'd be better off modelling some of the geometry into
                        the ground, rather than using bumpmaps.
08:00:55 <DragonM> Anyway.  Bumpmaps are all one to me, so I'll bail.
08:00:57 <aloril> Sal: or this stuff could be extended to include MIM?
08:01:05 <DragonM> Speaking of funding, it's time to do some accumulation of
                        funding myself.
08:01:08 <DragonM> Later people.
08:01:13 <Sal> sure that too :)
08:01:15  DragonM  is away - Detached - messages will be saved.
08:01:44 <Sal> pse: its not my choice totally, but of the WF artists
08:01:51 <Sal> they say, I code
08:01:53 <pse> Sal: Which one??
08:01:59 <pse> Sal: Bloodsport?
08:02:08 <Sal> Hope (WIremonger)
08:02:10 <pse> Because that is overkill
08:02:14 <pse> Yeesh.
08:02:17 <Sal> yep, Doug too
08:02:26  pse  shrugs.
08:02:43 <pse> Well, whatever.
08:02:52  aloril  goes away for hour
08:03:00 <Azhrei> bye aloril
08:03:02 * pse  decides not to bother with the 3d client then.
08:03:06 <Sal> sorry, pse... I wish it was easier
08:03:24 <aloril> and when comes back adds this and 'exception/dialog'
                        discussion logs
08:03:37 <aloril> to page which is going to have link from
                        http://www.worldforge.org/website/protocols/
08:04:05 ** You are now known as aloril_away_1h
08:04:10 <pse> Sal: Well, it's not my problem. You're not gonna find the client
                        running on too many machines, though.
08:04:19 <Sal> pse, have you used blender?
08:04:32 <pse> Sal: Yes.
08:04:36 <Sal> pse, not on any low end computers, you're right.
08:04:49 <Sal> (that's what the 2d/text clients are for :)
08:05:23 <Sal> What do you think of blender? Its free...
08:05:29 <Azhrei> oh crap Who has recorded this evening chat, I NEED to get a
                        copy...
08:05:37 <pse> Blender is not free. We are not going to use it.
08:05:37 <Sal> supports all the advanced material properties that we need, and
                        animation
08:05:42 <Azhrei> Sal:Blender is impossible to learn ;)
08:05:45 <Sal> it isnt?
08:05:54 <pse> The format isn't open, and it doesn't export.
08:05:57 <Azhrei> soso...
08:06:02 <Sal> I was told it was free for non commercial use...
08:06:12 <Azhrei> There is the key... we may do commercial...
08:06:25 <arf> azhrei, i have a log since about 8pm EDT
08:06:32 <pse> The program is free, but unless you're willing to hack the
                        format yourself, we can't use it.
08:06:43 <Azhrei> arf could you e-mail it to me?? azhrei at earthling.net
08:06:48 <arf> ok
08:06:58 <Sal> Garg told me that .rib was specced somewhere... that got my
                        hopes up
08:07:00 <Azhrei> thank you, need to start writing a white paper ;_
08:07:09 <pse> .rib is not blender.
08:07:13 <Azhrei> Sal:it is
08:07:17 <pse> Go check out bmrt.
08:07:31 <Azhrei> rib is Renderman Image Buffer?? or soemthing like that
08:07:40 <Sal> eek, now I'm confused.  which format is blender? anyone know?
08:07:42 <pse> It's renderman something.
08:07:50 <pse> Sal: Blender is blender format. No export. Nuthin.
08:08:01 <pse> Not unless you pay for a key, and even then I'm not sure.
08:08:03 <Sal> ug
08:08:09 <Sal> that doesnt help us then.
08:08:30 <pse> Sal: Use .obj, or something silly like that.
08:08:33 <Sal> sigh this is tough
08:08:45 <Sal> but what free tool is there to edit .obj?
08:08:47 <pse> bryce: You have any opinions?
08:08:54 <pse> Sal: None. Lotsa converters though.
08:09:13 <Sal> any convertors form a format that a free editor edits though? :)
                        that's the issue
08:09:19 <Sal> form/from
08:09:39 <pse> There are few free formats. Almost everything exports to some
                        standard that can be converted.
08:09:51 <pse> Crossroads, and 3dwin are two conversion utils.
08:10:22 <Sal> I'm more interested in the editor though... I'll code support
                        for whatever format if it has the features we need, and the tool is
                        there
08:10:33 <Drew> Perhaps we can talk to the coders of some of these modellers
                        and assimilate them.
08:10:46 <pse> Sal: We've already figured this out.
08:10:50 <Azhrei> moray and pov been looked into??
08:10:58 <pse> Sal: Short of blender, there are no integrated 3d tools we can
                        use.
08:11:00 <pse> Azhrei: Yes.
08:11:25 <bryce> pse, I have a wide variety of opinions... on which subject?
08:11:41 <pse> bryce: On targetting extremely high end machines with xclient?
08:12:06 * fooz (walker@putc3218166.cts.com) has joined #forge
08:12:07 <brenda> OH cool, fooz!
08:12:14 <Drew> What would you consider extremely high end?
08:12:21 <fooz> my computer
08:12:23 <pse> Drew: A g400 and a geforce. :)
08:12:26 <bryce> oh, erm, well that would be sal's decision to make
08:12:52 <pse> bryce: Yes, but I was just wondering your opinion. You're the
                        only sensible one around sometimes. ;)
08:12:54 <bryce> what do you think sal?
08:13:02 <Sal> pse, it wouldn't run only on those machines
08:13:02 <Drew> Sal, I'll assume that you'll let people turn some of these
                        features off?
08:13:04 <bryce> hehe, well thanks.  ;-)
08:13:11 <Sal> yes, drew. that's correct
08:13:19 <bryce> I tend to be of the walk-before-running mindset
08:13:21 <Drew> So what's the problem?
08:13:26 <Sal> not sure :/
08:13:44 <Laurel> today's extremetely high end machines will probably be only
                        reasonably-high-end by the time anything's released anyway :)
08:13:56 <bryce> also I like to try to do things modularly... so my opinions
                        will tend to drift towards making the more high-endish features
                        shut-offable.  but that's just me.
08:14:08 <Drew> Sounds good to me.
08:14:11  Sal  nods to bryce
08:14:14 <arf> you mean shut-onnable :)
08:14:20 <Sal> sut-offable is good.
08:14:24 <bryce> of course.  ;-)
08:14:52 <Sal> pse, a merge with crystal space is planned... eventually
08:15:08 <Sal> when that happens well gain support for all sorts of 1st gen 3d
                        formats,
08:15:14 <bryce> but please don't ask me what that kind of a modularity would
                        entail for a 3d client, I've no clue.  ;-)
08:15:20 <Sal> ie quake 1, quake 2, etc. etc.
08:15:41 <pse> Sal: Hrm. well, I'm not saying anything about your skills as a
                        coder, but I just think it's ambitious to redefine the whole concept
                        of 3d game modelling.
08:15:50 <pse> There's a reason people specialize in low poly modelling.
08:16:17 <Sal> I'm not redfining pse, you saw the shot of a demo that runs on
                        my puter,
08:16:28 <Sal> bump mapping and co. are all standard features...
08:16:53 <Sal> all I'm really doing is 'enabling' the stuff. The artists do all
                        the work
08:17:19 <pse> Sal: But that's directly from the guys who built the g400 isn't
                        it? And that's hardly standard... maybe later, but like I said, it's
                        really ambitious.
08:17:33 <Sal> this kind of quality is totally possible, if we dont restrict
                        ourselves to primitive tools :)
08:17:42 <pse> Sal: You know, I can't tell if that makes our artists lazy or
                        very hard working.
08:17:43 <fooz> is it possible on my g200?
08:18:06 <pse> fooz: No.
08:18:23 <fooz> damn
08:18:31 <Sal> well I wish I could make everyone happy... its hard. the high
                        end ppl want high end...
08:18:48 <fooz> make stuff turn-offable
08:18:51 <fooz> like someone else said
08:18:58 <Sal> that's my current approach :)
08:19:06 <pse> fooz: You can't just turn off bumpmaps in a model and expect it
                        to look right.
08:19:26 <fooz> pse- you can turn off lightmap in Quake3 and it doesn't look
                        right, but it sure as hell is faster
08:19:30 <fooz> heh
08:19:35 <Sal> heh
08:19:38 <pse> fooz: Lighting is different.
08:19:48 <pse> fooz: I'm talking about the models themselves.
08:20:06 <Drew> Hmm, bumpmaps are applied to the textures, aren't they?
08:20:14 <Azhrei> goodnight all
08:20:18 <fooz> Drew- not on the g400, I think
08:20:24 <Drew> Night Azhrei.
08:20:42 <Sal> this one's cool too:
08:20:45 <Drew> Fooz, that would be odd. A bumpmap is a bumpmap, right?
08:20:46 <Sal> http://www.wojo.com/sferro/g4demo/g400demo0.jpg
08:21:02 <pse> Drew: Bumpmaps are texture independent.
08:21:27 <Drew> Ok, it seems the article I read on it was ass wrong then.
08:21:37 <fooz> it's probably hardware implementation dependent.. or something
08:21:41 <fooz> Sal- those are beautiful screenshots
08:21:41 <pse> Drew: What article did you read? And what did it say?
08:21:42 <Sal> Drew, yes you're right
08:21:58 <Sal> they modify a base texture, and only pertain to
                        lighting/shadowing
08:22:03 <Drew> What article? I dunno, it was a while back.
08:23:26 <Sal> fooz: They are... you should see it in real time though.
                        stunning.
08:23:37 <Drew> Well, those screens make bumpmapping look very appetizing.
08:25:01 <pse> I'm still trying to figure out if that's laziness or enthusiasm
                        on the artists' part.
08:25:24 <Sal> pse, how's it laziness?
08:26:10 <pse> Sal: It's easier to just create a model in the standard manner
                        than to design it specifically for a 3d engine.
08:26:47 <pse> Sal: There's a considerable amount of work bringing something
                        down to low res and getting the textures and whatnot looking good.
08:26:53 ** Azhrei has quit (Leaving)
08:27:14 <Sal> I agree there. The easiest way to add realism to, say wood, is
                        to add a bump map
08:27:21 <Sal> but how is that bad?
08:27:30 <Drew> Well, Doug's been kinda bad about making his models low poly,
                        but I don't think it's because he's lazy.
08:28:15 <pse> Sal: How is that bad? It's not bad. It's lazy. the same model
                        won't work for the lower ended machines. Maybe the model will, but
                        you'll need to do a second skin. Twice as much work to handle
                        anything less than the g400.
08:28:38 <Sal> pse, that's not how bump mapping works...
08:28:40 <Drew> Hmm, what about LOD?
08:29:06 <pse> Sal: It doesn't matter how it works. Remove a bumpmap from a
                        model and it looks horrible.
08:29:08 <Sal> you add a texture, + a black and white bump texture to create a
                        material.
08:29:23 <Sal> no, remove a bump map and it looks like it would in quake,
                        unreal, etc. etc.
08:29:39 <Sal> which only use one texture in its materials..
08:29:42 <pse> Sal: Not if the underlying texture is designed to use bumpmaps.
08:29:43 <fooz> the bumpmapped textures are probably precomputed and then
                        applied like a normal texture on models, right?
08:30:21 <Sal> well 3d hardware supports multiple texture stages, you put the
                        texture in stage 1, and the bump map in stage 2
08:30:35 <Sal> if you dont support bump maps, you skip stage 2, easy.
08:30:47 <pse> Sal: Look at it this way. You have a model. Very little
                        geometry, you want it to be fast. Under normal circumstances, you
                        make a skin that has shadows and whatnot to simulate bumpmaps.
08:31:14 <fooz> pse- it won't look that much worse, I don't think
08:31:36 <Sal> pse, plus xclient could automatically merse the two textures if
                        its that big of a deal
08:31:43 <Sal> merse/merge
08:32:06 <pse> Sal: Say you support realtime bump maps. When you do that, you
                        model and texture differently. Your textures don't take into account
                        the shadows and whatever, because that's what bumpmaps are for.
                        Remove the bumpmaps, you get a nasty looking model.
08:32:15  pse  sighs.
08:32:24 <fooz> if you really want something to go fast you'll make some visual
                        quality sacrifices anyways, right?
08:32:29 <Sal> also there are technique such as 'embossing bump mapping' that
                        work on old hardware, like the voodoo1.
08:32:31 <pse> Whatever. Nevermind. I give up. I don't care anymore.
08:34:30 <Sal> pse, I'm not sure what you want me to do...
08:35:15 <pse> Sal: I don't want you to do anything. I'm telling you that by
                        doing all the high end stuff, it causes more work to make it look
                        good across more platforms, and alienates some artists.
08:36:31 *** calil has quit (Ping timeout)
08:36:34 <pse> Sal: Not all of us have expensive modellers. Some people are
                        even dedicated to doing low-poly only. It doesn't hold well that
                        you're letting the other artists use standard models in a 3d game
                        just because they want to.
08:37:06 <pse> there's a reason lots of stuff is done the way it is. Giving in
                        to their demands is going to create a lot of extra work for everyone,
                        and a lot of inconsistencies.
08:38:20 <Drew> If it doesn't work out, it won't work out. But Sal's talked to
                        a lot of people about this, and it's what they want.
08:38:33 <arf> hmm, it's weird that none of the modelling and graphics format
                        discussion is on the website yet, or is it?
08:38:40 <pse> arf: Very little.
08:38:49 <Sal> pse, no offense to the 'non 3d studio crowd' or anything, but
                        that's really all the media that I have.  I was send ons of beautiful
                        stuff from Hope and Doug in .3ds format, and therefore I chose to
                        support it
08:39:16 ** chuck has quit (Connection reset by peer)
08:39:34 <pse> Sal: And if I sent you something in hash format, would you jump
                        on to support it? Probably not.
08:39:55 <Sal> If I said I would, would you do it? Probably not. :)
08:40:35 <arf> if reasons/history is not documented  it's understandable that
                        people are not using the same set of assumptions :)  
08:40:36 <pse> Sal: Would you? Because I am working on stuff in hash.
08:40:55 <Sal> But I'll say, if you make good quality stuff in hash, and send
                        it to me... that would seriously make me consider it.
08:41:00 <Sal> pse: of course I would
08:41:19 <pse> Sal: I see. Alright then. I'll send it to you soon as I'm done.
08:42:10 <fooz> pse is a pretty good modeller
08:42:23 <pse> fooz: Too bad I'm lazy. :)
08:42:35 <fooz> pse- so is I
08:42:45 <fooz> heh
08:43:21 <pse> Sal: You might want to look at
                        http://www.stmuc.com/thbaier/tools.html
08:45:18 <Sal> wow. lotsa juicy stuff in here :)
08:45:35  Sal is now known as Sal_zzz
08:45:52 <Sal_zzz> anyhow, its late here, I have work early :(
08:46:22 <Sal_zzz> so 'night all
08:46:39  cyanide (ojw@reggae-18-176.nv.iinet.net.au) has joined #forge
08:46:41  brenda  gives cyanide an appointment.
08:46:53 <cyanide> oh... thanks brenda
08:47:00 * pse  wonders why he can't come in here without arguing with people.
                        :)
08:47:17 <bryce> a regular contrarian you seem to be, eh?  ;-)
08:47:25 <fooz> pse, it's because you're angry from all those years of using
                        your p133..
08:47:25 <pse> bryce: indeed.
08:47:30 <pse> fooz: Shaddup. :)
08:47:47 <fooz> (:
08:47:56 <pse> bryce: I think I'll stick to the 2d client. I really have no
                        intention of working on something I'll not be able to play. :)
08:48:35 <fooz> pse, I'm telling you mean, once you get a G[24]00 you won't
                        care if that's all people can use ;)
08:48:49 <fooz> s/mean/man/
08:49:21 <pse> fooz: I care, because even if I did have a g400, I realize I'm
                        not the only one who cares to play the game. :)
08:49:33 <bryce> pse, you may think this inane, but I am well known to
                        oft-encourage a positive-feedback technique I term "carroting"
08:49:40 <fooz> nah.. everyone else should just get a matrox
08:49:53 <pse> bryce: ?
08:50:00 <arf> mmm, carrots
08:50:25  fooz  reboots in linux
08:50:50 <bryce> pse, what I have found in net projects is that a compliment
                        tends to work as good or better than a complaint.  you may have heard
                        of the ol' carrot vs. stick approaches?
08:51:05 <pse> bryce: Actually, i haven't.
08:51:11 <bryce> ah okay
08:51:20 <bryce> there are two ways to make a donkey move
08:51:24 <bryce> beat him with a stick
08:51:28 <bryce> or lure him with a carrot
08:51:36 <bryce> same can be done with humans
08:51:43 <pse> Hrm. I'm not sure that applies. I'm trying to stop the donkey
                        from moving. ;)
08:51:45 <bryce> threat of being fired == stick
08:52:14 <bryce> pse, same approach can be used to make a donkey go wherever
                        you wish (or stay still)
08:52:28 <pse> bryce: Hrm..
08:52:33  pse  ponders.
08:52:43 <bryce> what I have found in net projects, is that sticks don't work
                        so well
08:53:01 <pse> bryce: I would imagine not.
08:53:07  fooz  beats pse with a stick
08:53:09 <bryce> it is too easy for someone to just shut off the computer and
                        go do something else
08:53:23 <pse> bryce: I dunno. I guess I can't help it. In a world of
                        optimists, someone has to look for the potential problems.
08:53:28 <bryce> but you can get them addicted by using carrots.  ;-)
08:53:35 <pse> Hehehe.
08:53:46 <bryce> pse, ah it just requires craftiness
08:53:51 <arf> problems != sticks, problems are exciting challenges :)
08:53:59  pse  could understand if sal were implementing that stuff in say...
                        2 years, when it would probably standard.
08:54:26 <bryce> here is a derivitive technique
08:54:34 <pse> But as it stands, game modelling is inherently different from
                        standard, and it's not a good idea to mix both.
08:54:36 <bryce> say you have ten monkeys
08:54:40 <pse> Not right now anyway.
08:54:46 <bryce> 9 of them do what you wish, and one does not
08:54:50  Laurel  thinks it'll take 2 years to actually have "users".
08:55:15 <bryce> you can either a) beat the one who did it wrong, so that next
                        time he doesn't do it that way
08:55:17 <pse> Laurel: Probably, but no reason to alienate testers while we're
                        developing. :)
08:55:21 <fooz> pse, you even HAVE a 3D card?
08:55:23 <bryce> or b) give the other 9 carrots.
08:55:52 <pse> fooz: somewhere, yes. :)
08:56:08 <bryce> I would offer that (b) will be more likely to make sure most
                        of the carrots do it the right way the next time
08:56:15 <fooz> bryce, what if the last one is more of a broccoli person
                        anyway?
08:56:20 <fooz> err, monkey
08:56:21 <fooz> :)
08:56:29 <arf> s/carrots/monkeys/ ?
08:56:32 <pse> What if the monkeys didn't like carrots to begin with? :)
08:56:42 <bryce> well, if he's a lost cause, you've not wasted your time with
                        him.  ;-)
08:56:48 <Laurel> pse: I suppose.  I guess it's not really relevant to me
                        anyway, since I don't have a 3d driver for my nvidia-- card.
08:56:49 <bryce> oh, monkeys like carrots.
08:57:15 <bryce> arf, oops, good catch
08:57:19  Laurel  watches bryce advocate cannibalism.
08:57:21 <pse> bryce: Yeah, but what if they were a bizarre breed of monkey
                        that only ate fillet mignon? :)
08:57:46 <arf> that's where recruiting and orientation come in...
08:57:54 <bryce> then establish an eatery and charge for food transactions
08:57:59 <fooz> if I were a monkey, I'd develop a greater liking to steak, so
                        people would give me steak to do what they wanted
08:58:12 <pse> bryce: that'd work if it was a lost cause, but it's not. There's
                        a long way to go, and this is jumping ahead too far too fast.
08:58:14 <bryce> mmm, steak
08:58:36 <fooz> pse, xclient is all 3D like U9 correct?
08:58:38 <bryce> pse, well I'm not talking at all about your particular
                        situation...  just in general
08:58:40 <pse> When a g400 is dirt cheap and there are tons of free modellers
                        and animators to work with. Fine.
08:58:56 <pse> bryce: Well it would apply. Maybe. It depends. I dunno. :)
08:59:02  pse  gives up on the 3d client.
08:59:04 <pse> fooz: Yep.
08:59:25 <fooz> pse, if you really wanted to use the 3d stuff you'd probably
                        have decent hardware to play it on anyway
08:59:38 * You are now known as aloril
08:59:59 <pse> fooz: I've got the hardware if I need it. It's just not my
                        personal box.
09:00:05 <fooz> pse, I doubt Quake would even run well on your p133, why do you
                        expect to use xclient on it? :P
09:00:08 <bryce> pse, the proper response when someone does something in a way
                        you dislike, is to find someone else who is doing something you do
                        like, and give them a compliment.  ;-)
09:00:25 <fooz> bryce, is anyone doing what he likes?
09:00:56  pse  snickers.
09:01:26 <Laurel> my client supports really low end hardware :)
09:01:40 <pse> Laurel: Which client is that?
09:01:47 <Laurel> text ;)
09:03:03 <pse> Laurel: Now that's the one I'm really looking forward to. :)
09:03:17 <fooz> yeah
09:03:19 <pse> Laurel: So what's it going to be like when it's done? Mud-style?
09:04:27 <Laurel> yep.
09:09:08 ** cyanide has quit (Connection timed out)
09:12:43 <pse> Laurel: Any chance you could make it moo style instead? ;)
09:13:42 <pse> bryce: Where's that spec on whitepapering?
09:14:03 <arf> CB
09:14:09 <Laurel> pse: output should be reasonably configurable.. you'd
                        definitely be able to alias commands to moo commands.
09:14:17 <pse> Laurel: Nifty.
09:14:24 <fooz> heh
09:14:35 <pse> fooz: What heh?
09:14:51 <fooz> pse, heh
09:16:02 <arf> heh heh
09:16:08 <fooz> heh
09:16:11  fooz  hehs.
09:16:30  arf  wears a silly grin
09:16:36  pse  ponders.
09:30:07 *** calil (~Larsson@su5-2.ida.liu.se) has joined #forge