Has anyone gotten Doris to work? I tried the sample scripts from http:///doris.sf.net, which are supposed to show the teapot, but the scripts don't even contain teapot data. Anyway, I coun't get any of the scripts to work..
Anyone got Doris working?
Posted by Biep on Tue 02 Aug 2005 12:19 PM — 11 posts, 45,503 views.
While this may be connected to Lua, it has nothing to do with MUSHClient. Try some place like The LUA Language Board:
http://board.univ-angers.fr/main.php
of one of the others you can find using the words 'lua' and 'forum' in google.
Oh, and BTW. The reason the 'example' doesn't produce anything, if I had to guess, is that the guy who made the page wrote the sentence in a confusing way. It should probably have been more like:
Above are some screenshots of what the program looks like in action. Below is a simple example of the code you might use, but doesn't 'actually' do anything.
Personally, while it looks vaguely interesting, until the guy can show some real examples, the only thing this seems to have going for it is the use of Lua. Programs like POV-Ray www.povray.org have been around for years and specifically avoid OpenGL and DirectX, as do nearly all programs like Maya, when producing a final image, because the OpenGL and DirectX systems where designed for animation and games, not photorealism. Basically, all professional systems use a physics based system, though some of the cheaper ones use a hybred, which fakes some things with the card, to speed things up slightly, but still does much of the final result using a physics system.
So, you might be asking, why if its so much better do they not make cards that do that? Well... They do. The problem is that they are so little used that there is little desire to improve them as fast or as much as OpenGL and DirectX based cards, which are 'good enough' for games and the initial design step of movies, as well as most things like architecture. Also, finding software to use the cards would be almost impossible. And finally, the cheapest of them is probably slower than POV-Ray, which costs nothing, while the card costs maybe 5-6 times what a single, brand new and best of the best, gaming machine would. Game machine = $1,200 more or less, 'one' physics based card, by itself = $6,000-$7,200, just at a rough guess. ;)
Anyway, while Doris looks interesting, its also a dime a dozen type project. Everyone now a days is designing something that uses OpenGL or DirectX, then patting themselves on the back for managing to use something that was 'specifically' designed to be easy for even a moderately skilled game developer to manage. lol I am still looking for a true opensource and non-comercial restricted physics based raytracer though. I guess that makes me, by todays stadards, insane. ;)
http://board.univ-angers.fr/main.php
of one of the others you can find using the words 'lua' and 'forum' in google.
Oh, and BTW. The reason the 'example' doesn't produce anything, if I had to guess, is that the guy who made the page wrote the sentence in a confusing way. It should probably have been more like:
Above are some screenshots of what the program looks like in action. Below is a simple example of the code you might use, but doesn't 'actually' do anything.
Personally, while it looks vaguely interesting, until the guy can show some real examples, the only thing this seems to have going for it is the use of Lua. Programs like POV-Ray www.povray.org have been around for years and specifically avoid OpenGL and DirectX, as do nearly all programs like Maya, when producing a final image, because the OpenGL and DirectX systems where designed for animation and games, not photorealism. Basically, all professional systems use a physics based system, though some of the cheaper ones use a hybred, which fakes some things with the card, to speed things up slightly, but still does much of the final result using a physics system.
So, you might be asking, why if its so much better do they not make cards that do that? Well... They do. The problem is that they are so little used that there is little desire to improve them as fast or as much as OpenGL and DirectX based cards, which are 'good enough' for games and the initial design step of movies, as well as most things like architecture. Also, finding software to use the cards would be almost impossible. And finally, the cheapest of them is probably slower than POV-Ray, which costs nothing, while the card costs maybe 5-6 times what a single, brand new and best of the best, gaming machine would. Game machine = $1,200 more or less, 'one' physics based card, by itself = $6,000-$7,200, just at a rough guess. ;)
Anyway, while Doris looks interesting, its also a dime a dozen type project. Everyone now a days is designing something that uses OpenGL or DirectX, then patting themselves on the back for managing to use something that was 'specifically' designed to be easy for even a moderately skilled game developer to manage. lol I am still looking for a true opensource and non-comercial restricted physics based raytracer though. I guess that makes me, by todays stadards, insane. ;)
It does appear to have working examples for each screenshot (click each screenshot and scroll down). Although, unless the stuff you download includes examples, I don't think they are complete examples (unless a 'teapot' is a built-in object).
However, he doesn't list anywhere what you actually need to download to get it all working, and the two downloads he does provide (GLUI and doris.exe) still is missing things. GLUI isn't packaged by him, just provided to download, and doris seems to be a normal application, and doesn't bring any documentation (or examples) with it.
However, he doesn't list anywhere what you actually need to download to get it all working, and the two downloads he does provide (GLUI and doris.exe) still is missing things. GLUI isn't packaged by him, just provided to download, and doris seems to be a normal application, and doesn't bring any documentation (or examples) with it.
Quote:
Anyway, while Doris looks interesting, its also a dime a dozen type project. Everyone now a days is designing something that uses OpenGL or DirectX, then patting themselves on the back for managing to use something that was 'specifically' designed to be easy for even a moderately skilled game developer to manage.
If straight OpenGL and DirectX are so easy to manage, why do you think there are so many libraries e.g. Ogre3d to name just one out there to make it all easy? Have you ever written a game using OpenGL or even using one of the helper libraries?Anyway, while Doris looks interesting, its also a dime a dozen type project. Everyone now a days is designing something that uses OpenGL or DirectX, then patting themselves on the back for managing to use something that was 'specifically' designed to be easy for even a moderately skilled game developer to manage.
Besides, it appears that Doris is more of a binding than an actual application. A binding is always useful, especially when the language doesn't have one . . .
No need to jump all over the poor guy.
1. I doubt he's looking for photo-realism. Probably just wants to make a nifty little GUI for his MUD.
2. A teapot is a primitive in OpenGL. Just one of those little quirks.
3. DirectX is a royal pain in the butt to use. OpenGL, however, can be confusing, but it is far from verbose and only requires a single DLL for most functionality.
I might look at this Doris to see if I can make sense of it myself. If I could make a 'built-in' GUI instead of having to startup a separate app and use UDP, I'd much prefer that. Probably easier to just use wxLua in the end, though.
1. I doubt he's looking for photo-realism. Probably just wants to make a nifty little GUI for his MUD.
2. A teapot is a primitive in OpenGL. Just one of those little quirks.
3. DirectX is a royal pain in the butt to use. OpenGL, however, can be confusing, but it is far from verbose and only requires a single DLL for most functionality.
I might look at this Doris to see if I can make sense of it myself. If I could make a 'built-in' GUI instead of having to startup a separate app and use UDP, I'd much prefer that. Probably easier to just use wxLua in the end, though.
If what you want is a GUI and not a 3d display, you'd indeed be better off using a binding to a GUI toolkit e.g. FLTK, wxWidgets, etc. Doris doesn't seem to be for non-3D applications.
To address your point #3, that's why libraries exist to bridge (as much as possible) the differences between OpenGL and DirectX and let you "just program" without having to worries about the intricacies of the inner library. (Again, to the greatest extent possible.)
To address your point #3, that's why libraries exist to bridge (as much as possible) the differences between OpenGL and DirectX and let you "just program" without having to worries about the intricacies of the inner library. (Again, to the greatest extent possible.)
Wasn't trying to jump all over him, though it might have seemed like it. My point was that its not quite as amazing a project as it seems. As for the teapot, its an object used by just about every developer of one of these imaginable, even POV-Ray, which comes with several different versions, three of which use the vertexes from the original teapot to construct other things over the surface of the original. Now the same scene would probably be done using some version of the "Trace" command, which follows the surface of an object and returns 3D points, which can be used to position other objects, like adding random grass to a landscape, etc.
Look familiar?
http://www.3d-canvas.com/3DCanvasDocumentation/tutorialraytracing.htm
http://en.wikipedia.org/wiki/Utah_teapot
And here also:
http://ccs-pk.chace-school.net/2004_05_01_ccs-pk_archive.html#108499227809434506
which shows all three of the advanced variations that come with POV-Ray. Teapot1.pov, not shown, is the 'basic' one, with no fancy tricks. The same guy has posts for the examples of a lot of other scenes, including two he posted thunmbnails for from http://www.povray.org/community/hof/ in his "Raytracing" posts.
So, yeah, its a very common mesh, so common its been around since at least 1994, when the the sample scenes for POV-Ray version 2.2 was provided with the book "Ray Tracing Worlds With POV-Ray", which originally read the data from a .raw file, containing the individual corners. The sample scenes have since been updated to use an include file, which has all the data in the triangle primitive, to avoid the time and overhead of reading in the entire .raw file using a program loops and macros. Its far more common now to use exporters and converters to get from some other format to POV-Ray than to read raw numbers.
Look familiar?
http://www.3d-canvas.com/3DCanvasDocumentation/tutorialraytracing.htm
http://en.wikipedia.org/wiki/Utah_teapot
And here also:
http://ccs-pk.chace-school.net/2004_05_01_ccs-pk_archive.html#108499227809434506
which shows all three of the advanced variations that come with POV-Ray. Teapot1.pov, not shown, is the 'basic' one, with no fancy tricks. The same guy has posts for the examples of a lot of other scenes, including two he posted thunmbnails for from http://www.povray.org/community/hof/ in his "Raytracing" posts.
So, yeah, its a very common mesh, so common its been around since at least 1994, when the the sample scenes for POV-Ray version 2.2 was provided with the book "Ray Tracing Worlds With POV-Ray", which originally read the data from a .raw file, containing the individual corners. The sample scenes have since been updated to use an include file, which has all the data in the triangle primitive, to avoid the time and overhead of reading in the entire .raw file using a program loops and macros. Its far more common now to use exporters and converters to get from some other format to POV-Ray than to read raw numbers.
The reason the teapot is so common is that it encapsulates, in a single mesh, nearly every nifty (i.e. difficult) feature for renderers. Basically, the quality of the teapot is an unofficial sort of measure of the quality of your graphics package.
Which is actually a bit silly, since a lot of newer meshes, especially when including UV mapping, etc. would be a far better example of what they can do. I wouldn't be surprised if the model exist back when DKBTrace, which POV-Ray is the decendent of, first appeared on the Amiga. lol
Well, right, the teapot is sort of a historical joke of sorts. It's not actually a measure of performance (hence my 'sort of' in the post above), but if your library can't render teapots, it obviously stinks. :-)
Hmm. And here I thought the old joke was a reflective sphere over a checkered plane... Though, truth be known, scanline renderers, like in graphics cards, can't really do that one at all. They can 'fake' one, but not generate a true reflection of the plane. But yeah, if you can't manage a teapot, then you really have a major problem.