Majik 3D MMORPG IRC meeting Wed Aug 02, 2000

Session Start: Wed Aug 02 20:19:03 2000
*** Now talking in #majikmeeting
*** Topic is 'Majik 3D meeting 8.30 pm EET 000802'
<kaido> =)
<eleril> hiya kaid
<kaido> hi eleril :)
<eleril> hmm i think once i get pretty far with this drago gonna try for lowpoly version of it for the game
<eleril> it talked about using some shaders of max in the plugin for max do they work when you export to .hx ?
<origon_> :P, dunno
* eleril is to use to using shaders eep
<eleril> gotta learn textures i guess
<origon_> what are those? :)
<eleril> shaders liek procedurals
<eleril> like wood, tile, marble
<eleril> stripes
*** Brethel has joined #majikmeeting
<eleril> wb Brethel
<eleril> Brethel have you had much time to do more sketches?
<Brethel> no
<eleril> :(
<Brethel> but I have one bigger picture ready
*** dazzt has joined #majikmeeting
<dazzt> Hoplaa
<eleril> cool
<origon_> ooh
* eleril hops
<eleril> can we see? :)
<eleril> hi dazzt
<dazzt> Sorry I'm a little late, win2k boots too long :)
<dazzt> Everyone present?
<eleril> namhas yet
<origon_> not nampu
<eleril> hes coming though
<Brethel> kaput and luxem couldn't attend?
*** namhas has joined #majikmeeting
* namhas hops around.
<eleril> i guess not they didnt email or anything but i hope to get them the meeting logs
<origon_> hop
* eleril hops
<dazzt> Ok, let's start in a sec
<eleril> did the list make much sense namhas, dazzt?
<namhas> a sec, i must go to shop until it closes (9pm eet). you others can begin.
* eleril hands the floor over to namhas and dazzt when their ready
<namhas> yes the list did make some sense.
<dazzt> I can start with some introduction to sr etc
<dazzt> Everyone alive? :)
* origon_ hops around
* kaido hops.
* eleril hops around
* namhas hops around.
<Brethel> hmm
<dazzt> So, as you probably have read the announcement we now have surrender 3d and surrender umbra (after it is finished, few weeks) available for our use
<dazzt> Surrender 3D is a 3d visualization library, which can utilize many different underlying 3D APIs such as DirectX, OpenGL and Glide
<dazzt> It also has it's high-performance software renderer so you could be able to play the game with a fast computer without a 3D card
<dazzt> (Oh, and if you have anything to ask feel free to interrupt me at any time)
* origon_ hops
<dazzt> Of course, as sr is only a library, it doesn't make the game automagically look any better
<dazzt> It provides a good framework for us to build the client on by making different things easier
<dazzt> (Oh, and umbra makes the game automagically go faster but I'll return to that later) :)
<dazzt> Surrender is built to have features found in 3ds max, so if you are a 3dsmax user you are in a good position
<dazzt> There exists a .hx (surrender 'hoax' format) exporter plugin and another plugin for defining exact material properties for 3dsmax
<eleril> will there be other exporter for lightwave, truespace etc as well?
<dazzt> For other 3D formats, we need to do some work. We need a lightwave support at Taika so I'm currently doing a lightwave object/scene importer
<dazzt> So we will be able to load lightwave objects/scenes directly into surrender
<dazzt> Truespace can also be considered, I checked out the format and it didn't look that difficult
<dazzt> Surrender will be replacing the plib library we used before
<dazzt> so now we need to port the plib specific code to surrender
<origon_> Are there simple coverters 'whatever2hx'?
<dazzt> Only a 3dsmax plugin that writes hx
<origon_> ok
<dazzt> The .hx format is not a requirement, it's just a dummy format that makes files sr can easily read
<origon_> so .3ds could be used directly as well?
<dazzt> Most probably we will have our own 3D format in the future to support LODs etc
<dazzt> Yes .3ds could be used if we would make the importer
<dazzt> But at the moment it's much easier to load .3ds into 3dsmax and export it to .hx
* namhas hops around.
<dazzt> For texture formats bmp, tga, pcx and jpeg are supported by default
<dazzt> (In addition to flic, avi and mpeg, but they aren't really that useful) :)
<origon_> will we not use animated textures?
<dazzt> Personally I feel you can't do good textures with simple animations
<dazzt> But hmm, maybe they could work on the user interface
<dazzt> Anyways we'll use if we need them
<dazzt> But for the moment don't use avis as object textures :P
<origon_> for an example when making fire, 2d tiles
<eleril> k
<dazzt> I'd like to do fires with a particle system instead of an animation
<origon_> ok
<origon_> can software renderer emulate everything a 3d card can make?
<dazzt> Yes
<dazzt> Though you can trust me it gets slow if you want all the filtering and stuff :)
<origon_> nice
<origon_> :)
<dazzt> But in any case it's 5-10x faster than the DirectX reference software renderer
<dazzt> Surrender also has an optimized math library for different processors (486, pentium, pentium pro, pentium mmx, pentium II, pentium III and 3DNow)
<dazzt> That will help a lot on the geometry side, because at the moment sr doesn't support hardware T&L (no directx7 support)
<dazzt> Also sr will limit our platform selection
<origon_> only win32 and linux?
<dazzt> Currently there exists versions for windows and linux, but current linux version is not actively supported and has only glide support. We need to add the opengl support for linux
<dazzt> It shouldn't be too hard as opengl is already supported on windows
<dazzt> Any questions?
<dazzt> (Before I'll move to umbra)
* origon_ shakes his head
<eleril> will we be able to use a 3d card and
<eleril> the renderer accelereation together to achieve a faster speed?
<eleril> or will the user simply need to choose between software render or 3dcard ?
<dazzt> Theoretically it could be possible (no support from surrender) but downloading the frame contents from 3D card is insanely slow so it's not practical
<eleril> ah k no more questions
<dazzt> But surrender does it's best performance-wise
<dazzt> I can tell you that the optimizations on the software renderer are quite insane :)
<eleril> cool
<dazzt> It has a small compiler built into itself that generates the most efficient code for each situation etc :P
<origon_> eew
<dazzt> So basically when you add a new material to surrender it generates an efficient code to render exactly that material's properties
<dazzt> Actually the software renderer is very useful while coding because the 3D card drivers aren't usually very stable, but when running in software you can't crash windows
<dazzt> But then to Umbra
<dazzt> Umbra is a visibility optimizer, i.e. we give it a list of objects and it tells us back what objects are visible from our viewpoint
<dazzt> What makes it different is that all the previous visibility optimizers have required much preprocessing (bsp-trees, portal generation etc)
<dazzt> while umbra is totally dynamic
<dazzt> Basically we just dump stuff into umbra while we walk on the world and for each frame we ask it what we should draw
<origon_> at an object basis, not polygon?
<dazzt> Umbra works in the image space so it actually calculates on the pixel-level what we can see
<dazzt> Umbra needs the polygon information for calculations but it tells us on the object level
<origon_> k
<dazzt> So generally very large objects should be split to several
<dazzt> And by very large I mean objects that you can mostly see only partially
<dazzt> For example, if you are modeling a dungeon make different hallways different objects
<origon_> do objects behave differently if their connecting vertexes are on the exact same location compared to a single object..?
<dazzt> Performance-wise, the Hybrid guys have done some tests with umbra, they made a scene with thousands of random teapots with thousands of polys each so that the scene did not fit into memory
<dazzt> Without umbra, it's many many seconds per frame, with umbra it's like 30fps :)
<origon_> ooh
<eleril> sweet
<dazzt> It can be used to predict what models we need to have in memory
<dazzt> So you don't need to have for example a large dungeon in memory at once
<dazzt> Though if you make models that big we'll be eating many dvds ;)
<dazzt> But origon, yes the connecting vertices are problem then
<dazzt> Not about their location but because you can't have smooth shading over the surface
<dazzt> between two objects
<origon_> nod
<dazzt> I'll leave that to artists, make it so that it looks good :)
<eleril> would it be best then to hide such a joint behind for example a wood beam?
<origon_> make them where the corner should be sharp anyways..
<dazzt> For example, yes
<dazzt> It's not my problem :)
<eleril> k :)
<dazzt> Umbra also supports portals, which are a sort of magic mirrors that lead to entirely other world. For example a dungeon can be separate from the world with it's entrance defined as a portal so when the entrance comes into a view the dungeon is rendered instead of a hole in the ground
<dazzt> When you apply a transformation to a portal so that it points back to the same environment you are in we can easily create mirrors
<origon_> what happens if they enter the portal? :)
<dazzt> We just move them inside the dungeon object
<dazzt> Hopefully the dungeon has another portal that leads back to surface so you can see and walk back outside ,)
<origon_> well, the portal shows the side facing you
<origon_> when entering the mirror, you land in yourself :)
<dazzt> No, we don't allow entering mirrors ;)
<origon_> doh
<dazzt> But with portals the world can be logically divided
<dazzt> So that the dungeon is loaded from disk when the portal comes near enough
<dazzt> And is again discarded when it goes too far away
<eleril> will the portals cause a noticeable loading time?
<dazzt> And if the portal is not in view, the entire dungeon does not need to be rendered when we are on the surface
<dazzt> The dynamic loading causes disk activity, we try to minimize it by keeping the loading code in another low-priority thread that runs simultaneously
<eleril> ah
<dazzt> But if something delays the disk driver too much it can cause a little jumps
<dazzt> If you have two processors it should be totally smooth as the other cpu can load stuff from the disk while another is rendering
<dazzt> Oh btw the surrender software renderer also supports multiple processors so you get over 190% speed boost if you have two etc
<dazzt> But to summarize, from artists' point of view you don't need to consider umbra too much. Just keep in mind not to make huge objects that have only a small part visible at each time, divide it into smaller objects
<origon_> nod
<eleril> nod
<dazzt> Questions about Umbra?
* origon_ shakes his head
<eleril> Umbra handles depth and such as well for example up to 1000 meters visiable in the distance then fog?
<dazzt> A virtual occluder can be made that discards everything after 1000 meters, it's not hard
<eleril> ah ok
<eleril> could the distance be adjustable by users so as to adjust there fps rate?
<origon_> will distance to horizon be dynamical?
<origon_> something like 'keep fps at >50'
<dazzt> That could be better implemented as a part of LODs, if the fps is not enough we change to lower detail level
<eleril> k
<dazzt> Oh and umbra also supports contribution culling, i.e. we don't need to display an object that doesn't contribute much to the final image (only a few pixels or something)
<eleril> ah similar to backface culling?
<origon_> such an arrow rushing for you :)
<eleril> ah yes
<dazzt> But I'll try to get a far-away horizon with clever LOD usage and then only adjust the amount of stuff on the ground and secondary stuff such as sky as a detail slider
<origon_> k
<origon_> using a table of distance to objects?
<origon_> if 200<x<400, lod=3?
<dazzt> There are four types of culling, view frustum culling (remove objects that aren't inside camera viewport), backface culling (remove faces that aren't facing you), occlusion culling (remove objects that are hidden by other objects) and contribution culling (remove objects that don't contribute to final image)
<dazzt> We'll calculate "what is the amount of error if we used a smaller lod" and then adjust that error value over distance
<dazzt> So for geometry near you, much less error is tolerated. For mountains far away you don't really care anything else other than the basic shape
<origon_> so at a start, we need to model 3 lod levels for each object or something?
<dazzt> We'll see. The alternatives are that either you model each LOD level individually or we code a polygon reduction system
<dazzt> For the time being you don't need to care.
<eleril> ah k
<Brethel> uh, syslogd got mad
<origon_> nod
<dazzt> And if we really have too much time a progressive mesh could be implemented, ie. we can adjust the level of detail by telling "Gimme 124-vertice representation on this object, plz"
<dazzt> But that would be quite much work
<dazzt> But about ongoing stuff, the heightmap has now the highest priority
<origon_> when will you need it?
<dazzt> As soon as you can get it
<dazzt> :)
<origon_> hum :)
<origon_> have you made any progress since the pics harum took?
<dazzt> The only problem is again time, I'll try to make more time to code majik on weekends etc, have been busy lately with work etc
<dazzt> I have hacked the code a bit but nothing major yet
<eleril> will you be able to test portions of the done hieghtmap so to speak by leveling out areas not done to flat?
<dazzt> Of course
<dazzt> I can test stuff with any heightmap but it will definitely look better when the heightmap matches the terrain information
<origon_> will it take long until we can alter the world from the 3d interface?
<eleril> ah
<dazzt> Probably :)
<eleril> after height map is complete what will be the next priority 3d wize?
<eleril> err wise
<origon_> landscape objects maybe?
<dazzt> The idea of heightmap is to get a coarse definition of the world. For starters all the details will be generated but later on it'd be nice if you would be able to edit terrain on a smaller scale
<dazzt> Current priority codewise is to convert existing code to use Surrender
<dazzt> Which can be done while you're working on the heightmap
<dazzt> And the Linux OpenGL port would also be a good thing
<eleril> ah
<eleril> does around the 17 of this month sound about right for the height map needed to be done?
<dazzt> After you get some versions of the heightmap done, it'll be easier to start editing terrain generation and parameters
<origon_> i read that you can export lights with objects from 3dsmax
<origon_> does this need to be coded to be supported?
<dazzt> I'll be away for the rest of the week starting tomorrow (assembly 2k), and the next weekend we have some laser war with friends so I don't have that much time, I'll try my best but my bet is that you'll come first with the heightmap than I with the port
<dazzt> Entire 3dsmax scenes can be imported with just a few lines of code
<dazzt> One point about lights. Umbra also supports regions of influence. What this means that we can have lots of local lightsources, umbra will tell us what lights affect what objects :)
<origon_> so lights at one object will affect other objects?
<dazzt> Uh, you can have many lights as long as you don't have too much lights affecting a single object at a time
<eleril> ah
<eleril> will flickering lights be possible?
<dazzt> Sure
<origon_> but that needs some code?
<dazzt> Of course, but it should be fairly easy to do
<dazzt> We just derive our own light from surrender light that changed it's intensity randomly
<dazzt> changed -> changes
<origon_> and sun will hopefully cast shadows?
<dazzt> The Surrender Artist's Guide can be browsed at http://www.majik3d.org/~dazzt/srdoc, l/p: majik/mod3ller
<dazzt> Well world without shadows is a quite dull one
<dazzt> So, I think I have said what I needed to. Any questions before I head to sauna?
<dazzt> I'll put a log of this online and mail the url to majik-design
<eleril> how will we go about handling the water ?
<eleril> k
<eleril> an aditional heightmap?
<dazzt> The sea can be hardcoded to client but the rivers that are too small to be fit on the map must be somehow defined separately
<dazzt> No good ideas yet (before we get a client with editor capabilities)
<eleril> ah
<eleril> what type of animation system might we use?
<origon_> dynamic water, that chooses it's own way? :)
<dazzt> Origon volunteers in coding that? :P
<origon_> :>
<dazzt> While you're at it you could code a distributed network of the clients so that each client calculates erosion for a small part of the world all the time
<dazzt> And make it also have a distributed weather prediction
<dazzt> :)
<origon_> duh :)
<eleril> that reminds me will we have weather ?
<dazzt> Eventually of course
<eleril> what will we have in next version of the client?
<dazzt> Atleast sr support and a new landscape (again) :)
<eleril> cool :) a few new characters?
<dazzt> Atleast the Kaput's new model
<eleril> buildings will have to wait for next version as well as landscape?
<dazzt> But one thing I'd like you to keep in mind, that now that we have access to Taika's technologies even if we would not be coding majik directly the technologies behind it are improving
<eleril> ah cool!
<dazzt> But if you don't have any more questions I'll head to sauna
<origon_> mpg intro?
<origon_> :
<origon_> )
<dazzt> Or ask more questions and I will answer them slightly later
<Brethel> well, what did you talk about? :)
<dazzt> Blaa mpg sucks, realtime rocks more ;)
<dazzt> Brethel, you were afk all the time? :)
<dazzt> Brethel, I'll post an irclog of this so you can read later ;)
<Brethel> ok
<eleril> might we have in game movie/animations for example after completing a great quest?
<Brethel> maybe animations perhaps
<dazzt> The problem with movies are that they are huge and as our main distribution medium is still internet .. well you get the idea. People might not want to download hundreds of megs with a modem
<eleril> oh yes almost forgot
<dazzt> :)
<Brethel> cool animations then
<eleril> is most of this information not to go public?
<origon_> heh, design-maillist is public
<dazzt> No big secrets here
<eleril> oh ok
<eleril> :)
<dazzt> :)
<dazzt> Or then this is just a big hoax, the -dev laugh our asses off here ;)
* eleril is pretty much out of questions for now :)
<dazzt> -dev denies knowledge!
* origon_ slams a hammer to the table
* eleril begins pulling out hair
<dazzt> Ok. I'll be back after sauna
* origon_ hops
<eleril> might could we see new picture Brethel your working on ? :)
<Brethel> well, it's quite big (A2) so I need to scan/take a picture of it somehow :P
<eleril> ah
<Brethel> Maybe I should sell it away when it's ready (convention could be an ideal place) ~50FIM or so :)
<origon_> not worth more? :P
<origon_> what is the motive?
<eleril> hmm i estimate i can get these 2 islands done in around 2-4hrs straight or probably less
<eleril> uh oh oops forgot to ask about ice
<eleril> on heightmap
<origon_> hum
<origon_> how would you like this scene, its is mid-night, all light is a flickering fire and the stars, player characters roaming around, and blocks of stone are scattered .. i want that :)
<eleril> yea :)
<kaido> i guess my attendance is no more needed. so i'll go off-line
* origon_ waves
*** Disconnected
Session Close: Wed Aug 02 22:33:22 2000