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->hill->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> 
