glelite-deve Mailing List for glElite
Status: Alpha
Brought to you by:
tksuoran
Menu
▾
▴
glelite-deve — General developer list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(22) |
May
(3) |
Jun
(2) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(8) |
Dec
|
|---|
|
From: <ktu...@ya...> - 2001-11-24 01:38:28
|
I've tested the programs and gave a look at the source. I'm also
perusing the documentation, which seems to be exhaustive. As for the test
programs, they are very good as a simple introduction to the framework, good
work. They seem to show that OpenGL calls are completely encapsulated inside
the framework classes, is that true ? Anyway, it should be said that
documentation is not a problem with this project :) I hope I had more time
to contribute...
...so, what's being worked on now ?
---
[]s, Andrei de A. Formiga
----- Original Message -----
From: "Timo K Suoranta" <tks...@cc...>
To: <gle...@li...>
Sent: Wednesday, November 21, 2001 1:48 PM
Subject: [Glelite-deve] Released 1.63
>
> Have a look at http://glelite.sf.net/
>
> The new release contains a few very simple
> and small example programs which I hope
> you could have a look at and give some
> feedback. Thanks!
>
>
> -- Timo Suoranta -- tks...@cc... --
>
>
>
> _______________________________________________
> Glelite-deve mailing list
> Gle...@li...
> https://lists.sourceforge.net/lists/listinfo/glelite-deve
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
|
From: Timo K S. <tks...@cc...> - 2001-11-21 15:48:43
|
Have a look at http://glelite.sf.net/ The new release contains a few very simple and small example programs which I hope you could have a look at and give some feedback. Thanks! -- Timo Suoranta -- tks...@cc... -- |
|
From: Timo K S. <tks...@cc...> - 2001-11-07 13:45:52
|
> I was thinking that the Planets, Moons, Bases, and Ships > would use the 3D modeling that is used. Using plain 3D models such as 3DS or LWO is simple in glElite, as it can already load and show Lightwave objects pretty nicely. Last time I checked the 3D object class hierarchy in Crystal Space it lacked some functions I needed, and it did not have Lightwave loader then. I don't know about the present situation. The current 3D object model class hierarchy in glElite is actually a frontend, a flexible API. It is not very good for drawing, in fact it is very unoptimized. I plan to add backend optimizers later. > the 3D model (adding more objects for detail around > your landing site) or do a 'perspective shift; and > switch to the Terrain generator with the buildings > for the StarPort being modelled. Once you get close > enough to most Planets or Moons, you only see thelocal > environment plus what ever is overhead anyways. This is the idea in general, but it does not cover terrain. Terrain must be look something decent from any possible altitude, and if you try modelling Earth so that it looks good from 10m, 1km, 10km, 100km and thousands of kilometers, you will notice that a making even a simple sphere mesh for this is very diffucult. The ROAM addresses most of the problems in a convenient way. > modeling, lighting, sprite, and object library systems > in place that could be vary useful. I was thinking that > if glElite was using portions of CS, then both projects I have checked Crystal Space couple of times, and the architecture is a little, em, different. It would be beneficial to analyse the differnecies, document those, and maybe merge some features if it seems possible. > would benefit. Maybe your 3D Terrain can be another > plugin to CS in the long run? The terrain ROAM code is not mine. It is written and maintained by Sean O'Neil. I have added some very small tweaks and suggestions only. -- Timo Suoranta -- tks...@cc... -- |
|
From: Steven W. <swi...@so...> - 2001-11-06 18:09:02
|
I was thinking that the Planets, Moons, Bases, and Ships would use the 3D modeling that is used. When your landing on a Planet or Moon you use either the 3D model (adding more objects for detail around your landing site) or do a 'perspective shift; and switch to the Terrain generator with the buildings for the StarPort being modelled. Once you get close enough to most Planets or Moons, you only see thelocal environment plus what ever is overhead anyways. I agree that the indoor part isn't useful, but it does already have a modeling, lighting, sprite, and object library systems in place that could be vary useful. I was thinking that if glElite was using portions of CS, then bot hprojects would benefit. Maybe your 3D Terrain can be another plugin to CS in the long run? On Tuesday 06 November 2001 11:55, Timo K Suoranta wrote: > > CrystalSpace is basically only libraries. I could see > > it being used for 2D & 3D graphics at least instead of > > glElite duplicating a lot of the work. It is for indoor > > and outdoor use (including a terrain engine). > > The indoor part is not currently intereting for glElite. > The terrain engine for glElite has some special requirements. > One of them is that the planet is spherical, not simple > heightfield. > > > -- Timo Suoranta -- tks...@cc... -- -- S.W. swi...@so... --------------------- Check out Terminus from http://www.vvisions.com/terminus/ And join the games at http://www.Terminuspoint.com/ --------------------- |
|
From: Timo K S. <tks...@cc...> - 2001-11-06 17:55:58
|
> CrystalSpace is basically only libraries. I could see > it being used for 2D & 3D graphics at least instead of > glElite duplicating a lot of the work. It is for indoor > and outdoor use (including a terrain engine). The indoor part is not currently intereting for glElite. The terrain engine for glElite has some special requirements. One of them is that the planet is spherical, not simple heightfield. -- Timo Suoranta -- tks...@cc... -- |
|
From: Steven W. <swi...@so...> - 2001-11-06 17:50:54
|
CrystalSpace is basically only libraries. I could see it being used for 2D & 3D graphics at least instead of glElite duplicating a lot of the work. It is for indoor and outdoor use (including a terrain engine). I was looking around for OpenSource projects similaar to the commercial program Terminus and it seems to me that those two projects have a lot over overlap. On Tuesday 06 November 2001 11:40, Timo K Suoranta wrote: > > Have you people thought of using the CrystalSpace libraries > > for the low level structure of your game? > > Which libraries and for which purposes? > > I have very briefly looked into CrystalSpace, but last time > I checked it there was little that I could have found useful. > > If there is something useful, it probably will be used when > it's needed. > > Anyone tried glElite/Teddy 1.61 yet? I added autopilot and > two wingmen. > > > -- Timo Suoranta -- tks...@cc... -- -- S.W. swi...@so... --------------------- Check out Terminus from http://www.vvisions.com/terminus/ And join the games at http://www.Terminuspoint.com/ --------------------- |
|
From: Timo K S. <tks...@cc...> - 2001-11-06 17:40:53
|
> Have you people thought of using the CrystalSpace libraries > for the low level structure of your game? Which libraries and for which purposes? I have very briefly looked into CrystalSpace, but last time I checked it there was little that I could have found useful. If there is something useful, it probably will be used when it's needed. Anyone tried glElite/Teddy 1.61 yet? I added autopilot and two wingmen. -- Timo Suoranta -- tks...@cc... -- |
|
From: Steven W. <swi...@so...> - 2001-11-06 17:35:19
|
Have you people thought of using the CrystalSpace libraries for the low level structure of your game? -- S.W. swi...@so... --------------------- Check out Terminus from http://www.vvisions.com/terminus/ And join the games at http://www.Terminuspoint.com/ --------------------- |
|
From: Timo K S. <tks...@cc...> - 2001-10-18 14:10:32
|
TIS 17th Oct 2001 (Version 1.58): - Fixed Camera and PostElement - Fixed view frustum culling - Fixed LightWave Color reading - Fixed new char strlen missing + 1 bugs causing crashes - Fixed configure script SDL_image and SDL_mixer detection - Initial support for sprites (flares) - Initial support for cabins - Initial support for polygon offset in lightwave objects - Initial original object modelling - Initial code for atmosphere tracing, not tested - Picking seems to be mostly broken Also includes initial networking code. -- Timo Suoranta -- tks...@cc... -- |
|
From: Timo K S. <tks...@cc...> - 2001-10-05 09:26:38
|
TIS 5th Oct 2001 (Version 1.55): - Fixed building problems - Now uses config.h - Integrated optional TinyGL OpenGL subset rendering - Cleaned up source dependencies by (re)moving some include directives I also updated GettingStarted.html and glElite homepage to use stylesheets. -- Timo Suoranta -- tks...@cc... -- |
|
From: Timo K S. <tks...@cc...> - 2001-08-27 13:59:50
|
Yet another bugfix release. This time only bugfixes: New roam code fixes roam bugs, lightwave loader code fixed. I would like to hear something from those of you who have not contributed anything to the project so far. Let me know if you have been just busy or simply not interested any more. Thanks! -- Timo Suoranta -- tks...@cc... -- |
|
From: Timo K S. <tks...@cc...> - 2001-07-31 12:10:07
|
I have updated CVS to version 1.46, which is also on the glelite.sf.net webpage as .tgz. You'll also need the data.tgz file. Changes: TIS 31st Jul 2001 (Version 1.46): - Fixed materials, should now work in linux too - Fixed texturemapping a little - Fixed scanner - Integrated bits of Celestia - Improved GUI a bit - Changed input processing -- Timo Suoranta -- tks...@cc... -- |
|
From: Timo K S. <tks...@cc...> - 2001-07-04 10:48:20
|
> Downloaded SDL image lib 1.2.0 and SDL 1.2.1 and recompiled project, 0 > errors 0 warnings. Try to start Teddy and I get the Teddy debug console and > then the main screen tries to initialize and I get: Fatal signal: > Segmentation Fault (SDL Parachute Deployed) in stderr.txt Could be missing files; get www.cs.helsinki.fi/~tksuoran/TeddyRelease.zip The next release will include updated build and running instructions. I'm waiting for Chris Laurel to accept LGPL for Celestial, so that I can include parts of Celestial with Teddy. -- Timo Suoranta -- tks...@cc... -- |
|
From: Tate O. O'K. <jo...@ne...> - 2001-07-02 05:08:46
|
Ok, Downloaded SDL image lib 1.2.0 and SDL 1.2.1 and recompiled project, 0 errors 0 warnings. Try to start Teddy and I get the Teddy debug console and then the main screen tries to initialize and I get: Fatal signal: Segmentation Fault (SDL Parachute Deployed) in stderr.txt Any ideas? Thanks |
|
From: Timo K S. <tks...@cc...> - 2001-06-29 06:30:00
|
> I have just checked out the new version of Teddy and compiled it and I'm > getting a file not found error on SDL_image.h which you've #included in > GraphicsDevice.h You will need SDL_image library. See www.libsdl.org - libraries section. > Are you using a newer version of the SDL now? Yes, SDL 1.2.1, but it is the SDL_image which you need. I should have added these new dependencies to CHANGES & README. Sorry about this. > Also I was not able to commit my changes because the repository > states I don't have write access. Does anyone else have this problem? It could have been temporary problem with sourceforge; I've had lot of those. Try again during few days and let me know if the problem remains. -- Timo Suoranta -- tks...@cc... -- |
|
From: Timo K S. <tks...@cc...> - 2001-06-28 13:58:15
|
Greetings, I released version 1.45 today. Changes include: TIS 28th Jun 2001 (Version 1.45): - Cleanups - Initial texture mapping support - New vertex types - Some material system rework - Updated Win32 midi player The material system rework has temporarily broken lightwave object loader. I hope to add soon procedural textures (used for skybox), fix the lwo loader, and experiments with multitexturing. Currently issues which are waiting to be solved: - Vertex presentation - Viewspace objects Vertex presentation issue involves vertex array and related NVidia extensions, displaylists, potential vertex format, and displaylists. Currently Teddy does not use vertex arrays nor any NVidia extensions nor displaylists. The release 1.45 has following Vertex types: Vertex, SmoothVertex, TNVertex and CNVertex. The Vertex is plain vertex, SmoothVertex adds normal, and TNVertex adds texture coordinates to SmoothVertex, while CNVertex adds color. I don't know yet what would be best way to present vertices of potentially different formats when vertex buffers and/or displaylists are added to Teddy. All ideas are welcome. Sean O'Neil will hopefully send me an update to his Roam code eventually. He is now working for a company which uses his code, so he needs to ask permission from the company before he can release the improved code. The viewspace objects issue is about what is the best way to get lensflares and laserbeams drawn. There is some code in Scenes/PostElement.*, but I haven't actually tested it for a while, after a lot of changes since it was originally written. I would also like to have alpha blending effects as soon as viewspace objects issue is solved. I have recently joined BlitzBasic 3D beta testing team. I have signed NDA, so I can not discuss that any further. I have teamed up with another BB3D beta tester Ed Upton though, and we are working on BB3D game project not unlike glElite. It may turn out that we will use BB3D as fast prototyping and eventually write the final application on top of Teddy. It's been quite quiet on glelite development. Namely, I have not got a single CVS commit from any of you, and very few questions. What I would like is that you would get the latest version adn have a look in the code, and ask questions about it. I understand that you may be busy on other projects, but even a single question per month or two would make me much happier ;) -- Timo Suoranta -- tks...@cc... -- |
|
From: Phillip M. <q95...@to...> - 2001-05-29 23:28:33
|
I'm doing good, just finished my last assignment fo rthe semester. Hooray, all that stinking prolog out the way! :) Work is going well. It is very bust at the moment :( So that measn absolutely zero spare time. Its been like that for about a month now. Oh well. Ho hum. Good news is my next work computer should have a 3d accelrator in it, so I'll be able to use it to do some elite work! yay! Phil On Tue, 29 May 2001, Timo K Suoranta wrote: > > Greetings, > > A new version 1.43 of Teddy / glElite has now been uploaded to > Sourceforge files, Sourceforge CVS and glElite homepage. > > Changes: > - Code cleanups; removed Physics and Kamin > - Now understand several arguments, like -width, -heigh > - Simple command parser in Console > - Initial dog-fight scene with multiple camera windows > (type 'minicam' to console to open the other window) > - Fixed view frustum culling > - Matrix now [col][row] - just like OpenGL > - Updated ROAM code > - Integrated float-quaternion and double-position ModelInstances > - Initial support for Frontier First Encounter ships > - Fixed Visual Studio files which were gone wrong in 1.36 > > You can try FFE ship interpreter by typing 'add ffe' to console. > You can load lwo files by typing 'load lwo' to console. > You can add roam to scene by typing 'add roam' to console. > > Copyrighted data files are now distributed separately. > > How is everyone doing - studeis, exams maybe?) > > > -- Timo Suoranta -- tks...@cc... -- > > > _______________________________________________ > Glelite-deve mailing list > Gle...@li... > http://lists.sourceforge.net/lists/listinfo/glelite-deve > |
|
From: Timo K S. <tks...@cc...> - 2001-05-29 14:46:05
|
Greetings,
A new version 1.43 of Teddy / glElite has now been uploaded to
Sourceforge files, Sourceforge CVS and glElite homepage.
Changes:
- Code cleanups; removed Physics and Kamin
- Now understand several arguments, like -width, -heigh
- Simple command parser in Console
- Initial dog-fight scene with multiple camera windows
(type 'minicam' to console to open the other window)
- Fixed view frustum culling
- Matrix now [col][row] - just like OpenGL
- Updated ROAM code
- Integrated float-quaternion and double-position ModelInstances
- Initial support for Frontier First Encounter ships
- Fixed Visual Studio files which were gone wrong in 1.36
You can try FFE ship interpreter by typing 'add ffe' to console.
You can load lwo files by typing 'load lwo' to console.
You can add roam to scene by typing 'add roam' to console.
Copyrighted data files are now distributed separately.
How is everyone doing - studeis, exams maybe?)
-- Timo Suoranta -- tks...@cc... --
|
|
From: Timo K S. <tks...@cc...> - 2001-05-09 16:22:00
|
Experimental version of Frontier ship model interpreter: http://www.cs.helsinki.fi/u/tksuoran/ Also some graphics links in top of the page which I haven't had time to read through yet :I If you like playing detective, you could try helping me out trying to guess what all those hex values in ffedat.asm mean.. Some of them are guessed at: http://www.cs.helsinki.fi/u/tksuoran/FrontierMesh.cpp -- Timo Suoranta -- tks...@cc... -- |
|
From: Timo K S. <tks...@cc...> - 2001-04-26 09:15:52
|
> > Yes, I would like to have support for NVidia AGP vertex arrays, > > normal vertex arrays, compiled vertex arrays, displaylists etc. > > Total genericity can be a real bitch to implement... Not really. NVidia extensions are addition to normal vertex arrays, which part can be left untouched. My current architecture for Mesh displaylists was following: - beginUpdate() - update() - endUpdate() - draw() All the actual rendering code was in update(). The draw() method simply checked if displaylist was ok and called it, or called update() methods. The idea in beginUpdate() and endUpdate() was to prepare (begin and end) a new displaylist. This worked for displaylists, but there needs to be an abstract vertex and actual 'sending of vertices' to Projection in Elements for vertex buffers. > One thing I've been wondering is that would it be sensible to have > partially transparent surfaces at all? I mean, they'd require special I am not sure about this.. > building potentially huge data structures. On the other hand, > transparencies are pretty much a requirement for a good-looking engine > glow... ..because I was wondering if alpha blending with GL_ONE, GL_ONE would be enough? > I think that we should give the "must work with single texturing cards" > principle a boot in the aft section. If Teddy is going to target graphics > cards from the G400 up, it makes little sense to pretend that someone would > want to run Teddy-based programs in single textured mode. This can be done in two ways; multipassrendering, or simply rendering just one texture pass and forgetting about rest. Looks different, but runs on low-end. This is what I had in mind in the first place; being able to set the game to wireframe and monochrome rendering without lighting etc. for either nostalgy or low-end machine. > I don't have a very high opinion of the SDL threading interface; perhaps I don't know about this. SDL internally uses posix threads. Personally I hope that we can keep threads controlled with as little as possibly, hoping that the SDL interface would do. I have to agree that SDL threading interface is a little weird. -- Timo Suoranta -- tks...@cc... -- |
|
From: Kalle A. Sandstr\o. <ksa...@ik...> - 2001-04-26 00:06:13
|
On Tue, Apr 24, 2001 at 06:49:01AM -0700, gle...@li...= forge.net wrote: (I'm responding to the digest... Maybe I'll switch to "real" mailing list format at some point.) > Date: Tue, 24 Apr 2001 10:50:19 +1000 (EST) > From: Phillip Martin <q95...@to...> > To: Timo K Suoranta <tks...@cc...> > cc: mic...@no..., gle...@li... > Subject: RE: [Glelite-deve] Things to do >=20 > Sorry about not including the previous post in here, I'm using a unix > email client, and editing large bodies of atext is a pain. >=20 > Anyhow, my post is primarily about the having objectes draw themselves > issue. >=20 > My thought on the matter is that objects do not draw themselves, but > essentially create a data structure which the renderer then interpreets , > and sends off to the appropriate api. If a nice enough set of classes was > written that would easily define meshes, materials, colours, textures and > all that jazz, each object can create or have its own internal 3d > representation, then which is passed to the renderer for efficient > rendering. >=20 > This has the major benefits of:=20 > - Each object has the ability to define how itself is drawn > - the renderer can optimise any which way it lieks to draw the given > objects efficiently. Such optimsiations are away from the internal > objects. > - it would be easy to alter the internal meshes to use vertex buffers or > display lists without chaning the interface to those classes at all. >=20 I tried to do this with a previous research prototype. My data structure was a "state tree" -- the rendering optimized would then re-order the state changes for different primitive groups in the most efficient way for the underlying driver & hardware combination (perhaps based on benchmarks run on program startup, or something), trying to minimize the cost associated with state changes. Now I'll be the first to admit that this would only deal with state change cost (which seemed a good thing to concentrate on at the time; I can easily imagine how a glLoadMatrix of GL_MODELVIEW would be a serializing operation on a na=EFve hardware T&L driver), but the main lesson that I learned from this was that it's not worth the hassle if the primitive groups are too small. The main issues that I see in this approach would be "what kind of a data structure would be best for this?" and "what kind of data should we put in the data structure?". What the renderer will optimize for (speed, of course! but how?) would also be something to think about. --=20 Kalle A. Sandstro"m ksandstr &at& iki &dot& fi http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto 1ED7 C636: 7728 49D5 F784 D2DD D20F 63CF 655D F19E 1ED7 C636 |
|
From: Kalle A. Sandstr\o. <ksa...@ik...> - 2001-04-25 23:42:16
|
On Tue, Apr 24, 2001 at 04:47:23PM +0300, tsuoranta wrote: > > Perhaps we should also prepare for the (IMO) inevitable addition of > > graphics-card side vertex buffers by providing a kind of abstraction fo= r it. > > Nvidia, at least, seem to have their own extension for this. >=20 > Yes, I would like to have support for NVidia AGP vertex arrays, > normal vertex arrays, compiled vertex arrays, displaylists etc. Total genericity can be a real bitch to implement... > > One thing that I learned while writing one of my failed prototype 3d > > engines was that you can't really keep material handling separate from > > geometry handling. At the very least, for multitexturing (primitive per= -pixel > > point lights, that sort of thing), you'd need some kind of an interface= for > > the geometry to draw itself multiple times in a certain order, etc... >=20 > The current rendering architecture in Teddy does indeed have multiple > pass rendering. >=20 > http://glelite.sourceforge.net/doc/Mesh_cpp-source.html >=20 > See drawImmediate() and drawElements(). It currently does not support > multitexturing, which potentially would require a lot of changes to > the current architecture. I hadn't thought much about multitexturing > until this mail, since there is no textures in glElite / Teddy yet > at all. Multitexturing is important for visual quality; you can do some pretty neat things with it when used correctly (approximate per-pixel lighting comes to mind, as well as some rather surreal effects...) > The current implementation simply redraws every element multiple > times if required. For example, for hidden line removal to happen > when drawing wireframes, you have to first draw with filled polygons > and polygon offset, and then do a second pass with lines and no > polygon offset. You can also enable borders by using second pass. One thing I've been wondering is that would it be sensible to have partially transparent surfaces at all? I mean, they'd require special handling (i.e. "draw opaque surfaces first, then draw transparent polygons in a back-to-front order while making sure that they don't intersect") which may not be feasible on the polygon level without building potentially huge data structures. On the other hand, transparencies are pretty much a requirement for a good-looking engine glow... One way would be to add a 'flags' field (or a bunch of bool variables, whatever) to a Renderable entity and then reorder the visible object list so that first objects with only opaque surfaces would be drawn into an 'empty' color buffer and then objects with both opaque and transparent surfaces in an approximate back-to-front order. (Computing the back-to-fro= nt order can get pretty weird unless the objects could be partially rendered, or something. Object cutting is something I'm not going to touch with a ten-foot pole, however.) > Actually I think multitexturing is slightly different from multiple > passes like border lines above. With multitexturing you may not have > to actually render multiple passes, but I know no good method that > could do border lines in a single pass. Applying multitextures might > be simple to add to current Projection <-> Mesh architecture I think.. I think that we should give the "must work with single texturing cards" principle a boot in the aft section. If Teddy is going to target graphics cards from the G400 up, it makes little sense to pretend that someone would want to run Teddy-based programs in single textured mode. On a research engine I had about half a year ago, I tried to implement layered-texture stuff so that it would run on both single- and multitexturi= ng cards. The results were less than satisfactory; you can't do emulated per-pixel point lighting from multiple light sources with only one texture unit. > > Perhaps a good design would be to keep the "what happen ?" code > > separate from the "main screen turn on" stuff, so that if the game were > > run without networking the server object (or some such) would run on the > > local computer in a separate POSIX thread. >=20 > Yes, something like that. The simulation already runs in seperate > thread as SDL timer. Nope, I haven't protected anything with semaphores > as I should have.. yet :) I don't have a very high opinion of the SDL threading interface; perhaps we should provide our own abstraction of POSIX-style threading (i.e. threads, mutexes, conds, possibly read-write locks) in order to remain sane -- I mean, there supposedly is a POSIX threads implementation for win32 too, so it can't be that hard. (we might be able to cut'n'paste some code from SDL too ;-) --=20 Kalle A. Sandstro"m ksandstr &at& iki &dot& fi http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto 1ED7 C636: 7728 49D5 F784 D2DD D20F 63CF 655D F19E 1ED7 C636 |
|
From: Timo K S. <tks...@cc...> - 2001-04-24 13:47:36
|
> Perhaps we should also prepare for the (IMO) inevitable addition of > graphics-card side vertex buffers by providing a kind of abstraction for it. > Nvidia, at least, seem to have their own extension for this. Yes, I would like to have support for NVidia AGP vertex arrays, normal vertex arrays, compiled vertex arrays, displaylists etc. > the design... Maybe when I have more time I'll do something about the > physics engine. > > > It is possibly to tweak ROAM a lot. Currently there is a lot of slowdown .. > You mean it looks like a badly cut block of moldy cheese?-) No offense, > of course... Not; ROAM in 1.37 is simply broken. It does not adjust the level of detail based on camera correctly. I should recopy this code from 1.27, but I haven't bothered, since the new version of ROAM would be more important. > One thing that I learned while writing one of my failed prototype 3d > engines was that you can't really keep material handling separate from > geometry handling. At the very least, for multitexturing (primitive per-pixel > point lights, that sort of thing), you'd need some kind of an interface for > the geometry to draw itself multiple times in a certain order, etc... The current rendering architecture in Teddy does indeed have multiple pass rendering. http://glelite.sourceforge.net/doc/Mesh_cpp-source.html See drawImmediate() and drawElements(). It currently does not support multitexturing, which potentially would require a lot of changes to the current architecture. I hadn't thought much about multitexturing until this mail, since there is no textures in glElite / Teddy yet at all. The current implementation simply redraws every element multiple times if required. For example, for hidden line removal to happen when drawing wireframes, you have to first draw with filled polygons and polygon offset, and then do a second pass with lines and no polygon offset. You can also enable borders by using second pass. Actually I think multitexturing is slightly different from multiple passes like border lines above. With multitexturing you may not have to actually render multiple passes, but I know no good method that could do border lines in a single pass. Applying multitextures might be simple to add to current Projection <-> Mesh architecture I think.. > Perhaps a good design would be to keep the "what happen ?" code > separate from the "main screen turn on" stuff, so that if the game were > run without networking the server object (or some such) would run on the > local computer in a separate POSIX thread. Yes, something like that. The simulation already runs in seperate thread as SDL timer. Nope, I haven't protected anything with semaphores as I should have.. yet :) -- Timo Suoranta -- tks...@cc... -- |
|
From: Kalle A. Sandstr\o. <ksa...@ik...> - 2001-04-24 12:56:13
|
On Tue, Apr 24, 2001 at 11:58:32AM +0300, tsuoranta wrote: >=20 > > I tried checking the 'Teddy' module out but sourceforge seemed to have >=20 > Any luck now later? I'll try later today. > > Now, I'm sure that this is too early to start thinking about performance > > (the rest of you seem to be in feature mode anyhow ;-), but it might be >=20 > No, it certainly is important to get performance working well. Thats why > I reworked material management and as result there Projection between > ModelInstance/Mesh/Element drawing and View (OpenGL&Graphics context). > It is still missing vertex buffer. Perhaps we should also prepare for the (IMO) inevitable addition of graphics-card side vertex buffers by providing a kind of abstraction for it. Nvidia, at least, seem to have their own extension for this. (i.e. the idea is that the driver wouldn't need to copy vertex data from client side into the card's AGP buffers on every frame drawn; this could be a big win for static objects) > > worthwhile to explore other landscape rendering algorithms besides ROAM > > (which is commonly said to be too CPU-intensive to peg a modern T&L car= d). >=20 > Again, the version of ROAM currently included is a really badly broken. > The newer code uses vertex arrays etc., but it will mean some work before > I can integrate that into current code. Anyone willing to do the > integration?) =20 I have other projects currently (heh, about 3 or 4 of them ;-) so I can't really do much else than maybe give almost constructive criticism on the design... Maybe when I have more time I'll do something about the physics engine. > > Ideally, the not-ROAM landscape algorithm would produce results that lo= oked > > about the same as with ROAM, but consume less CPU time per vertex while > > possibly generating more vertexes. Having a second algorithm would also >=20 > It is possibly to tweak ROAM a lot. Currently there is a lot of slowdown > caused by the multifractal, which is really calculated in real time. It > would be a much better idea to cache fractal values somehow. Also you can > combine different fractal (or other height functions!); plasma for some > parts could be a lot faster. Also I am not happy with the currently > generated terrain. It is missing features, or something.. You mean it looks like a badly cut block of moldy cheese?-) No offense, of course... > What I did not tell it the previous mail (about rendering architecture) > was that I wan't to support rendering preferences *per Projection* in > addition to per ModelInstance. This means that I can tell Projection that > 'Now use flat shading, no textures' or 'Now use monochorome, wirefrane > rendering with hiddenline removal' and that will apply to all objects. > You can already turn lighting on and off in the Teddy 1.37. Also see > UIobjects.cpp for material / rendering options per ModelInstance. >=20 One thing that I learned while writing one of my failed prototype 3d engines was that you can't really keep material handling separate from geometry handling. At the very least, for multitexturing (primitive per-pix= el point lights, that sort of thing), you'd need some kind of an interface for the geometry to draw itself multiple times in a certain order, etc... Perhaps a kind of Visitor pattern would be useful here, like wotsisname (sorry, can't remember) said - that would remove some code redundancy from the Renderable (I'm assuming that you still have Renderables; I haven't looked at the code in ages...) implementations. > Networking is tighly coupled to the physics simulation (that is what > I call anything that 'happens' in the game). So far I have only worked > on the rendering engine. There exists a very very primitive physics > simulation, but I have no plans to improve it much in the near future. >=20 > It is true that networking affects a lot of design for physics simulation. > Thus we should encapsulate the whole physics simulation as much as > possible from rest of the game. This is how it is possible to make > framework that works for both networked and non-networked games. Perhaps a good design would be to keep the "what happen ?" code separate from the "main screen turn on" stuff, so that if the game were run without networking the server object (or some such) would run on the local computer in a separate POSIX thread. > > http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr vii= lto >=20 > ^ ..not very international.. ^ It's not intended as such :-) --=20 Kalle A. Sandstro"m ksandstr &at& iki &dot& fi http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto 1ED7 C636: 7728 49D5 F784 D2DD D20F 63CF 655D F19E 1ED7 C636 |
|
From: Timo K S. <tks...@cc...> - 2001-04-24 08:58:44
|
> I tried checking the 'Teddy' module out but sourceforge seemed to have Any luck now later? > Now, I'm sure that this is too early to start thinking about performance > (the rest of you seem to be in feature mode anyhow ;-), but it might be No, it certainly is important to get performance working well. Thats why I reworked material management and as result there Projection between ModelInstance/Mesh/Element drawing and View (OpenGL&Graphics context). It is still missing vertex buffer. > worthwhile to explore other landscape rendering algorithms besides ROAM > (which is commonly said to be too CPU-intensive to peg a modern T&L card). Again, the version of ROAM currently included is a really badly broken. The newer code uses vertex arrays etc., but it will mean some work before I can integrate that into current code. Anyone willing to do the integration?) > Ideally, the not-ROAM landscape algorithm would produce results that looked > about the same as with ROAM, but consume less CPU time per vertex while > possibly generating more vertexes. Having a second algorithm would also It is possibly to tweak ROAM a lot. Currently there is a lot of slowdown caused by the multifractal, which is really calculated in real time. It would be a much better idea to cache fractal values somehow. Also you can combine different fractal (or other height functions!); plasma for some parts could be a lot faster. Also I am not happy with the currently generated terrain. It is missing features, or something.. > Then again, with the current OpenGL vertex buffer handling, the > geforce2 GTS won't be a bottleneck with simple (textured & lit) > primitives... I'm still using Matrox G400. Until very latest drivers, it's been a real pain. But now that I upgraded Duron 800 it's not so much pain, and latest drivers finally have fixed depth culling problems etc. What I did not tell it the previous mail (about rendering architecture) was that I wan't to support rendering preferences *per Projection* in addition to per ModelInstance. This means that I can tell Projection that 'Now use flat shading, no textures' or 'Now use monochorome, wirefrane rendering with hiddenline removal' and that will apply to all objects. You can already turn lighting on and off in the Teddy 1.37. Also see UIobjects.cpp for material / rendering options per ModelInstance. > powergaming weenies). Also, this sort of thing would need to be designed > into the game from day -1, before work starts on the "real" graphical > client. My personal opinion at the moment is that we first concentrate on framework aspects in Teddy. And do that in such way that it is possibly to use Teddy for both networked and non-networked games. I see no reason why it would work already that way. You can plug in networking any time you want. Networking is tighly coupled to the physics simulation (that is what I call anything that 'happens' in the game). So far I have only worked on the rendering engine. There exists a very very primitive physics simulation, but I have no plans to improve it much in the near future. It is true that networking affects a lot of design for physics simulation. Thus we should encapsulate the whole physics simulation as much as possible from rest of the game. This is how it is possible to make framework that works for both networked and non-networked games. > The "getting started" doc is pretty good. You might want to link > to Lars Wirzenius' using-cvs document > <URL:http://liw.iki.fi/liw/texts/using-cvs.html>. A link to the SDL > homepage would also be nice. I will be adding links, erm., soon. CVS book is also good one, as you can freely download and print it, too. > http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto ^ ..not very international.. ^ -- Timo Suoranta -- tks...@cc... -- |
