Menu
▾
▴
rama-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(3) |
Mar
(6) |
Apr
(2) |
May
(3) |
Jun
(5) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Peter S. <oph...@ar...> - 2001-08-28 21:55:53
|
One of the courses I went to at siggraph was on physical modelling = (simulation-based animation). I created this little application to play = with some of the things they talked about. Much of it is quite a hack, = so I wouldn't spend much if any time looking at the code. All in all it = took a little less than a day to create. This doesn't really have to do = with RAMA yet, but I plan to ramify it soon. :) http://www.aros.net/~ophiuchus/partplay-0.0.1.tar.gz It requires OpenGL and QT. Peter. |
|
From: Peter S. <oph...@ar...> - 2001-08-27 15:43:22
|
I just thought I'd give everyone (all two or three of you :)) a heads up = about the change of license with the latest rama release. I decided to = change it to the LGPL mainly so that it could link with the QT = non-commercial libraries for windows. I could have added exceptions to = the previous license, but I tought it would be better to have a slightly = looser license. btw, QT is fantastic! It is by far the easiest to use = GUI toolkit I've used. Peter. |
|
From: Peter S. <oph...@ar...> - 2001-08-25 21:26:39
|
Hey, guys. I've been working on the next RAMA release, which will include QT support. I ran into an interesting little problem. I created a double number spinner by deriving from QSpinBox which is an integer spinner. QSpinBox represents the number as an integer, but provides a couple functions that can be overridden to convert from the number that is in the box to the actual rep. I encountered a problem with this. Here is a small snippet that illustrates: double x = 41.9; int y 10; cout << (int)(x*y) << endl; // prints 418, not 419! This doesn't work on several gcc compilers (Redhat 6.2, 7.1, and cygwin 1.0). I tried this same code in MSVC 6, and it worked correctly. Using a float instead of a double seems to work, so I suppose I can get around the problem by using floats instead. Does anyone have a better idea? Thanks. Peter. |
|
From: Peter S. <oph...@ho...> - 2001-05-22 05:30:36
|
Hey, guys. I added wxWindows support to the latest RAMA release (0.0.7), which I just released. Try it out, and let me know if you encounter any problems. I'm going to spend some time on some 3d art stuff now, but I'll fix any problems that crop up. Peter. |
|
From: Peter S. <op...@in...> - 2001-04-24 04:44:18
|
Hey, guys. Just thought you'd like to know that I've been accepted to the graduate program at Ohio State University, and will be attending it in the Fall! I'll be studying CG for real! :) I'm not sure if that means that I'll have more or less time for RAMA. I suppose it means less, unless I can somehow incorporate it into a thesis. Peter. |
|
From: Peter S. <op...@in...> - 2001-02-10 06:58:41
|
Hi, Dave. > I've been converting textures to RAMA. I've done Pyramids and Flat. > The other fully functional textures will come in a bit, then I'll make > up a tarball. > > The problem I've had with Pyramids is that parameters are assigned it a > weird way. What I see is that even-numbered properties (not sure of > the RAMA term - "data channels"?) are for doubles (values), and > odd-numbered properties are for links. Is this right? Is it because > of type-safety issues? Can we make link and setvalue multiply by 2 on > their own, and just set props by number? This comes about because of a hack I introduced. The "ValueSwitch" class isn't a true channel. It is just a class that adds two channels to the texture parent, one for the float, and the other for the interface to the other textures. This was the easiest and simplest way to add channels that I could think of, but this really needs to be redesigned. Until then, I think the change you suggested is a good idea. Also, the channel interaction needs to be improved. > Can we create some class that's responsible for loading and saving and > managing textures, and that link and setvalue are member functions of? The link and setvalue functions are really just there to make the channels easier to use. I think this goes along with what I said above about improving channel interaction. Did you have something else in mind? > Speaking of loading, what'll it take to get loading working again? The > code says it's broken. You need to uncomment the load function, and comment out the create. I didn't have time to do this properly. > BTW, the properties for Pyramids are a recent addition - I gave it a > "center" x and y. I think this will be useful when it's used for > space-ship skins and stuff. Does the "center" parameter change the location of the peak? > Ideas on any of the above? We need a GUI :) Peter. |
|
From: David T. <no...@no...> - 2001-02-10 05:30:10
|
I've been converting textures to RAMA. I've done Pyramids and Flat. The other fully functional textures will come in a bit, then I'll make up a tarball. The problem I've had with Pyramids is that parameters are assigned it a weird way. What I see is that even-numbered properties (not sure of the RAMA term - "data channels"?) are for doubles (values), and odd-numbered properties are for links. Is this right? Is it because of type-safety issues? Can we make link and setvalue multiply by 2 on their own, and just set props by number? Can we create some class that's responsible for loading and saving and managing textures, and that link and setvalue are member functions of? Speaking of loading, what'll it take to get loading working again? The code says it's broken. BTW, the properties for Pyramids are a recent addition - I gave it a "center" x and y. I think this will be useful when it's used for space-ship skins and stuff. Ideas on any of the above? -- -Dave Turner | The corporation and its subordinate divisions shall -------------| have the sole and exclusive right to use the name, "Blue Star Mothers of America, Inc.", and no other organization shall use the name "Blue Star Mothers of America, Inc.". -US Code Title 36, Sec. 956 |
|
From: Peter S. <op...@in...> - 2001-01-28 18:16:03
|
Novalis, I've uploaded what I have done to TextureGen to http://members.nbci.com/ophiuchus42/rama/TextureGen-0.0.1b.tar.gz I updated TextureGen to use the new RAMA libraries, and began to make changes to allow it to compile under Cygwin. I created a class called ValueSwitch in "switch.cc" that will allow you to switch from a floating point value to a texture. Each ValueSwitch adds two data channels to the texture, one for the floating point value and one for the texture. This is likely to be a temporary implementation, but works for the moment. Adding the two channels to the texture allows the texture to save/load its information seamlessly using the new RAMA libraries. I have modified SpiralTexture and LeopardTexture to use ValueSwitches. The executable is currently set up to create the texture and then save it to "spiral.tg" and render it. To load "spiral.tg," comment out the create function, and uncomment out the loading code in TextureGen.cpp. They should be obvious to find. The executable also creates a file called "plugins.txt" that shows the textures that are in the library. Let me know if you have any questions. Oh, one last thing. The RAMA data channel that is used for the texture interface will create a new texture when it is loaded. This means that if you link multiple times to the same texture, when the resulting file is loaded, it will create multiple instances of the same texture instead of creating only one. Peter. |
|
From: Peter S. <op...@in...> - 2001-01-28 17:35:42
|
Boy, this list has been quiet lately! Anyway, I fixed some bugs in RAMA that I found while updating TextureGen code and uploaded the new release as 0.0.5c. Peter. |
|
From: Peter S. <op...@in...> - 2000-12-16 19:47:13
|
I've finished with mrt0.0.2 but have been having trouble uploading it to sourceforge. I submitted a report to them on Wednesday, but they haven't assigned anyone to it yet. I have a feeling they deal with help requests in order of popularity, so it may take a while. In the mean time, if you can't wait, I've made the tarballs available elsewhere. You'll need http://members.xoom.com/ophiuchus42/rama/rama-0.0.5b.tar.gz and http://members.xoom.com/ophiuchus42/rama/mrt-0.0.2.tar.gz Peter. |
|
From: Peter S. <op...@in...> - 2000-12-12 14:44:39
|
Hi, guys. I'm almost finished with the next version of mrt. There are still some very distinct render artifacts that I'll have to fix in a later release. Here are a couple of new images. The images aren't very compressed so they are a bit large. http://members.nbci.com/ophiuchus42/rama/box.jpg http://members.nbci.com/ophiuchus42/rama/sflake.jpg Hopefully, I'll be releasing mrt and rama bug fixes within the next couple days. Peter. |
|
From: Peter S. <op...@in...> - 2000-11-10 21:27:48
|
Hey, guys. I realize it's been a while since you last heard a peep from me; unfortunately I've been bitten by the evil beast of the real world. I won't get much more time until the end of January. I have still been working on RAMA in my spare time, but I haven't made much progress. I just added a new release (0.0.4b) and added Mare` Tracer to the downloadable modules. Both modules are compilable on both linux and windows (under cygwin) without any changes. I'm using GLUT to display the rendered image under linux, but I haven't been able to get Mesa to work under Cygwin, so only a jpeg image is created under windows. Let me know if any problems come up :) Peter. |
|
From: Peter S. <op...@in...> - 2000-08-22 04:49:24
|
Hey, guys. Over the last few days I have been resurrecting my old raytracing code (Mare` Tracer). Unfortunately, I hadn't left it in a very good state, so it took some time to get working. Originally, it had its own plugin architecture, but I modified it to use RAMA for extension loading/retrieving. Just to see how easy / difficult it would be, I created an adaptor extension for the Novalis' TextureGen plugins that I had modified earlier. This was actually very simple, and took less than an hour to do. The adaptor only links to TextureGen application code, and the TextureGen plugins are loaded at runtime with the other plugins. Here is an image generated by Mare` Tracer: http://members.xoom.com/ophiuchus42/rama/rama-mrt-tg.jpg The image uses sphere and infinite plane primitives. The sphere uses the TextureGen adaptor, which creates the same texture as in the last release Novalis sent me, along with a plastic lighting model. The plane doesn't use a lighting model, and has a checker texture applied to it. A fog environmental shader has been applied to the scene. Finally some progress! :) Peter. |
|
From: Peter S. <op...@in...> - 2000-08-06 11:45:33
|
Hey, guys. I apologize for the long term silence. I have been pretty burned lately. Anyway, yesterday I made a quick stab at converting Dave's texture generation program. I made a couple of changes to the rama source to get things to work. Two snapshots can be found here: http://members.xoom.com/ophiuchus42/rama Essentially, I just made some changes that would allow the application to use the extension loading code. I only changed two of the textures: SpiralTexture (which I made static) and LeopardTexture (which I made dynamic). Both work. I ran into a couple of problems: - arguments cannot be passed into the constructor for specialized extensions. I got around this by using deferred construction - an Init function that the application could call to initialize the texture. This is obviously not a good solution, and I'm currently thinking of a better one. - The RTTI and private inheritance of the standard implementation class (extimpl) won't work, because of ambiguities. This can be solved using virtual inheritance, but I don't think it's worth it. I think the separation of implementation from interface is too much of a pain to use, so I might just put extimpl into the top-level extension interface (Ext). - The current means of getting extensions from the database is somewhat clunky. I think bypassing the loaders all together will help. Also, the current implementation of the database should probably change - it currently inherits from the standard library vector class, and it isn't really a vector. - when I linked with exttools.so, the program crashes before anything else happens, but linking with exttools.a will work. I'm not sure how to go about fixing this one... any suggestions? - The way RAMA is currently installed is a bit of a pain. All objects need to be combined into one library (or two - see below), and all headers into a single directory. I'm also currently thinking of decoupling the extension interfaces from the loading code. This would allow others to use the extension loading libraries with essentially any type of program. The top-level interface would be Info, instead of Ext. The two sets of libraries can be separated like this: RAMA - extdata, interfaces, extimpl loader - exttools, info I guess that's about it. Comments are welcome! Peter. |
|
From: Peter S. <op...@in...> - 2000-07-10 02:43:53
|
Hi, Dave. > I've made a new "release". Note the new location: > http://web.novalis.org/programs/TextureGen.tar.gz > > BasicTexture is now the superclass of all textures. Sed (or Perl) could change > this if it's a problem. Most texturing functions now have their own subclass > of BasicTexture. Some texturing functions haven't yet been converted - mostly > the mappings and composites. > > I've started work on a DarkTree loader. This makes me realize that we need a > factory classmethod in BasicTexture (or maybe a TextureFactory class). This > will eventually have to deal with dynamically loaded textures and stuff, so > it's going to be RAMA-related. Send feedback and I'll do something. RAMA's factory is comprised of a single database of loaders. Every extension (plugin) has its own loader inside of the database. The database doesn't distinguish between statically loaded extensions (compiled into application) and dynamically loaded extensions, so the application deals with each in the same fashion. The database can be found in src/exttools/dbase. I haven't had much time to look at this yet, but now that I'm done with the latest RAMA release, I'll make this my priority. Aside from structure, do you want me to comment on general style? Have you given any thought to creating a project-independent texturing library? It would contain things like colors, turbulence/noise, and functions generally useful for creating textures (such as repeats, clamps, etc.). I talked about this a little bit with je (with Math3d and famps), and he suggested creating a separate project in sourceforge along the lines of Math3d. Would you be interested in working on something like this? Peter. |
|
From: Dave T. <no...@no...> - 2000-07-06 01:16:39
|
Peter Stuart wrote: > ----- Original Message ----- > From: David Turner <no...@no...> > To: Peter Stuart <op...@in...> > Sent: Monday, July 03, 2000 4:14 PM > Subject: Re: [Rama-devel] Re: texture generator > > > At 10:14 PM 7/1/00 -0600, you wrote: > > ><SNIP> > > > > I'm not really sure about having the texture generator deal with the > 3d > > > > math involved in normals. Of course, it makes some sense for it to do > it, > > > > but it's not easy, and it raises the bar the creation of new > > > > textures. DarkTree does some pretty hard-core stuff with > bump-mapping, > > > > which I'm not really sure we want to replicate, as it basically > includes a > > > > ray-tracer (I'm not 100% sure about this, but it looks like it). > > > > > >The texture app wouldn't have to do any lighting calculations. A lighting > > >extension would provide this to the app. At the very least, a diffuse > model > > >would be necessary to do bumpmapping. With RAMA, the texture app would be > > >able to use whatever lighting extensions others have written, without any > > >extra changes. > > > > What DarkTree does is treats bump mapping as actual bumps - hills cast > > shadows, for example. That's more than just modifying the normal. We > > should probably not attempt this. We should instead use standard (fake) > > bump-mapping (just modifying the normal). That involves only the problems > > listed below. > > > > I see what you mean now. I think you're right... we should avoid this for > now. It would probably require a displacement shader, and a renderer > (raytracer or other). Eventually, RAMA should be able to be used to add > these to the application relatively easily... at least that's how I envision > it :) We'll call that settled. > > > > > Bump mapping usually works by modifying the normal. The normal is a > > >vector > > > > in 3-space. Given that its length doesn't matter, it only needs 2 > > > > coordinates to control it. Most bump-mapping systems get two > coordinates > > > > per texture coordinate by representing the "height" of the surface at > any > > > > given point. The slope between each point and the surrounding points, > > > > combined with the old normal, gives the new normal. This is > sufficient > > >for > > > > all real surfaces. > > > > > > > > In the case of a 2d grayscale bump map, getting the normal is easy. > In a > > > > continuous texture, it's not as easy, because of questions of > > > > scale. Consider the following texture (side view) > > > > > > > > _________ ______ _________ > > > > \______/ \ / > > > > a^ b^ \_/ > > > > c^ > > > > If you merely choose "nearby" points to sample from (in the ascii art, > > > > point b where you want your normal), you could choose points a and c. > > >This > > > > would obviously be wrong. Choosing the correct points seems > difficult. > > > > > > > > Any ideas on how to handle this? > > > > > >That's a good problem. This is really just another version of aliasing > due > > >to point sampling. The only way that I can think of to fix it would be > > >supersampling, and even that wouldn't really fix it. > > > > > > > If possible I want to have the texture generator take no information > about > > > > where the texture is being used, except (x, y, z, t). > > > > > >I'm not following you here... > > > > > > Ah. That was the end result of a good deal of thought about a possible > > solution. On its own, it makes no sense, which is why you were confused > > :). I was thinking of sending the texture generator data (sorta like ds > > and dt) that would let it do the right thing, but then I decided that it > > wouldn't really work anyway. > > > > Maybe there should be some sort of epsilon value, and the slope will be > > measured (like in calculus) between f(x,y) and f (x + epsilon, y + > > epsilon). This could be user-adjustable until it "looks good". > > I think this will work. However, it will mean that some of the detail is > lost. For example, to get the -b slope above, epsilon would have to be > reduced to b-a (roughly). For a low sampling rate (maybe a sample at a and a > sample past the top of the +c slope), the +b, -c, +c slopes all disappear. > What do you think will happen should you randomize epsilon? A high sampling rate will cause some accuracy errors, because doubles only go so small, but I think that's preferable to the huge errors caused by low sampling rates. So, until we see a better idea, we will go with very small epsilons, and hope it works :) > > <SNIP> > > > > I'm not sure I see why time can't just be treated as another parameter > to > > > > get_color like x, y, z. This would be faster than having a special > > >purpose > > > > interface. > > > > > >This is a good question. My gut is telling me that time should be removed > > >from the interface. I don't know about you, but that is NOT a good enough > > >reason for me. I'm having difficulty thinking about this at an abstract > > >level... I need to get my hands dirty. At this point, I'm thinking that > > >parts of RAMA need to be revamped to work the way I'd like it to, but I > need > > >to verify that. Do you mind if I try to port your current code base to > use > > >RAMA? I think it would make it easier for both of us to talk about this > if > > >we have some concrete examples. (Or rather, if *I* had a concrete example > > >:)) > > > > I would like nothing more than that. There are a few issues, tho. When I > > last worked on the code (that tarball), I had a major mind-quake, and > > realized that I had been doing some things very wrongly. Here's the deal: > > > > When I first looked at Garg's screenshot of DarkTree, I tried to figure > out > > how it worked. What I came up with was that it had some basic textures > > (fractal/Perlin noise, rings, bricks, crackle), and some ways to combine > > them, and some ways to warp or deform them. These became BasicTexture, > > CompositeTexture, and Mapping. > > > > I was wrong. > > > > The correct thing to do is have one class of texture, and have each > texture > > (whether it's a basic, composite, or mapping texture) subclass it. Since > > the render function is render_dot (x, y, z, t), it's easy to do each thing > > separately. > > > > So, before you convert everything over, either change the code to reflect > > this, or let me do it. > > > > What needs to happen is: > > > > 1. Class Texture becomes the base class for all textures. > > 2. Each function (Crackle, Leopard, Add, Multiply, all of the mapping > > textures, etc) must get it's own class, which is a subclass of > > texture. You don't really need to do all of them - just enough to prove a > > point; we can do the rest as we get to them. > > 3. Texture must be modified in whatever way is necessary to make it > > extensible via RAMA. This is where the sticky problems of interface come > > in. Currently, I have each texture function in a grayscale only (one > > float) format. Coloring is done by applying a simple gradient to the > > results of render_float (x,y,z,t) . This is OK temporarily. > > > > Things like reflection, alpha, bumps, etc aren't covered. Eventually, > > they'll be part of class Tree, which will then call the render_dot_color > () > > and render_dot_float () functions of component textures. This is OK > > temporarily. > > > > My current interface is (x, y, z, t). I would prefer this to be kept > > as-is, at least until you try it. > > What? My gut feeling isn't good enough for you?? Heh heh... It's easy to change later :) > > > > > If you want to do this, do it and let me know. Otherwise, tell me and > I'll > > do the grunt work, and then let you do the RAMA-ization. > > I don't think I'll be able to get to it for at least another week. I'd like > to finish up the next version of RAMA, so that there will be a stable > version released before I change everything :) If you think you can get it > done in say two weeks (assuming time, inclination, etc...), go ahead and do > it. Otherwise, I can do it as part of the "RAMA-ization", (or how about > "RAMA-fication"?). It seems like you already have a good idea about what > needs to be done to make it more OO. I'll take a closer look at it in a > couple of days to see if I might have any suggestions to add. > OK, I'll re-write the class heirarchy. I'm going to at least flip through Design Patterns first (I got it for my birthday). > > > > > One last thing - I just updated the code at the address I gave > before - > > > > it's a little weirder now, but it produces output that's kinda neat > > >looking. > > > > > >I'm impressed... this looks very good. Where did you get the algorithms > for > > >the textures? > > > > Various online sources, and POV-Ray. I didn't actually copy an POV code > > directly, but some of my textures are *very* heavily inspired by it, most > > notably quilt and crackle. I don't know about quilt, but crackle is not > > original to POV-ray; it's one of a class of "cellular" functions. > > Hmmm... I guess I'll have to whip out my archived copy of the POV source > again :) > > I'm going to cc this to the RAMA development list - we should probably start > posting to the mailing list to get their help with this. I keep forgetting > to do that... > > Peter. -Dave |
|
From: Peter S. <op...@in...> - 2000-07-04 05:29:26
|
----- Original Message ----- From: David Turner <no...@no...> To: Peter Stuart <op...@in...> Sent: Monday, July 03, 2000 4:14 PM Subject: Re: [Rama-devel] Re: texture generator > At 10:14 PM 7/1/00 -0600, you wrote: > ><SNIP> > > > I'm not really sure about having the texture generator deal with the 3d > > > math involved in normals. Of course, it makes some sense for it to do it, > > > but it's not easy, and it raises the bar the creation of new > > > textures. DarkTree does some pretty hard-core stuff with bump-mapping, > > > which I'm not really sure we want to replicate, as it basically includes a > > > ray-tracer (I'm not 100% sure about this, but it looks like it). > > > >The texture app wouldn't have to do any lighting calculations. A lighting > >extension would provide this to the app. At the very least, a diffuse model > >would be necessary to do bumpmapping. With RAMA, the texture app would be > >able to use whatever lighting extensions others have written, without any > >extra changes. > > What DarkTree does is treats bump mapping as actual bumps - hills cast > shadows, for example. That's more than just modifying the normal. We > should probably not attempt this. We should instead use standard (fake) > bump-mapping (just modifying the normal). That involves only the problems > listed below. > I see what you mean now. I think you're right... we should avoid this for now. It would probably require a displacement shader, and a renderer (raytracer or other). Eventually, RAMA should be able to be used to add these to the application relatively easily... at least that's how I envision it :) > > > > > > > Bump mapping usually works by modifying the normal. The normal is a > >vector > > > in 3-space. Given that its length doesn't matter, it only needs 2 > > > coordinates to control it. Most bump-mapping systems get two coordinates > > > per texture coordinate by representing the "height" of the surface at any > > > given point. The slope between each point and the surrounding points, > > > combined with the old normal, gives the new normal. This is sufficient > >for > > > all real surfaces. > > > > > > In the case of a 2d grayscale bump map, getting the normal is easy. In a > > > continuous texture, it's not as easy, because of questions of > > > scale. Consider the following texture (side view) > > > > > > _________ ______ _________ > > > \______/ \ / > > > a^ b^ \_/ > > > c^ > > > If you merely choose "nearby" points to sample from (in the ascii art, > > > point b where you want your normal), you could choose points a and c. > >This > > > would obviously be wrong. Choosing the correct points seems difficult. > > > > > > Any ideas on how to handle this? > > > >That's a good problem. This is really just another version of aliasing due > >to point sampling. The only way that I can think of to fix it would be > >supersampling, and even that wouldn't really fix it. > > > > > If possible I want to have the texture generator take no information about > > > where the texture is being used, except (x, y, z, t). > > > >I'm not following you here... > > > Ah. That was the end result of a good deal of thought about a possible > solution. On its own, it makes no sense, which is why you were confused > :). I was thinking of sending the texture generator data (sorta like ds > and dt) that would let it do the right thing, but then I decided that it > wouldn't really work anyway. > > Maybe there should be some sort of epsilon value, and the slope will be > measured (like in calculus) between f(x,y) and f (x + epsilon, y + > epsilon). This could be user-adjustable until it "looks good". I think this will work. However, it will mean that some of the detail is lost. For example, to get the -b slope above, epsilon would have to be reduced to b-a (roughly). For a low sampling rate (maybe a sample at a and a sample past the top of the +c slope), the +b, -c, +c slopes all disappear. What do you think will happen should you randomize epsilon? <SNIP> > > > I'm not sure I see why time can't just be treated as another parameter to > > > get_color like x, y, z. This would be faster than having a special > >purpose > > > interface. > > > >This is a good question. My gut is telling me that time should be removed > >from the interface. I don't know about you, but that is NOT a good enough > >reason for me. I'm having difficulty thinking about this at an abstract > >level... I need to get my hands dirty. At this point, I'm thinking that > >parts of RAMA need to be revamped to work the way I'd like it to, but I need > >to verify that. Do you mind if I try to port your current code base to use > >RAMA? I think it would make it easier for both of us to talk about this if > >we have some concrete examples. (Or rather, if *I* had a concrete example > >:)) > > I would like nothing more than that. There are a few issues, tho. When I > last worked on the code (that tarball), I had a major mind-quake, and > realized that I had been doing some things very wrongly. Here's the deal: > > When I first looked at Garg's screenshot of DarkTree, I tried to figure out > how it worked. What I came up with was that it had some basic textures > (fractal/Perlin noise, rings, bricks, crackle), and some ways to combine > them, and some ways to warp or deform them. These became BasicTexture, > CompositeTexture, and Mapping. > > I was wrong. > > The correct thing to do is have one class of texture, and have each texture > (whether it's a basic, composite, or mapping texture) subclass it. Since > the render function is render_dot (x, y, z, t), it's easy to do each thing > separately. > > So, before you convert everything over, either change the code to reflect > this, or let me do it. > > What needs to happen is: > > 1. Class Texture becomes the base class for all textures. > 2. Each function (Crackle, Leopard, Add, Multiply, all of the mapping > textures, etc) must get it's own class, which is a subclass of > texture. You don't really need to do all of them - just enough to prove a > point; we can do the rest as we get to them. > 3. Texture must be modified in whatever way is necessary to make it > extensible via RAMA. This is where the sticky problems of interface come > in. Currently, I have each texture function in a grayscale only (one > float) format. Coloring is done by applying a simple gradient to the > results of render_float (x,y,z,t) . This is OK temporarily. > > Things like reflection, alpha, bumps, etc aren't covered. Eventually, > they'll be part of class Tree, which will then call the render_dot_color () > and render_dot_float () functions of component textures. This is OK > temporarily. > > My current interface is (x, y, z, t). I would prefer this to be kept > as-is, at least until you try it. What? My gut feeling isn't good enough for you?? Heh heh... > > If you want to do this, do it and let me know. Otherwise, tell me and I'll > do the grunt work, and then let you do the RAMA-ization. I don't think I'll be able to get to it for at least another week. I'd like to finish up the next version of RAMA, so that there will be a stable version released before I change everything :) If you think you can get it done in say two weeks (assuming time, inclination, etc...), go ahead and do it. Otherwise, I can do it as part of the "RAMA-ization", (or how about "RAMA-fication"?). It seems like you already have a good idea about what needs to be done to make it more OO. I'll take a closer look at it in a couple of days to see if I might have any suggestions to add. > > > > One last thing - I just updated the code at the address I gave before - > > > it's a little weirder now, but it produces output that's kinda neat > >looking. > > > >I'm impressed... this looks very good. Where did you get the algorithms for > >the textures? > > Various online sources, and POV-Ray. I didn't actually copy an POV code > directly, but some of my textures are *very* heavily inspired by it, most > notably quilt and crackle. I don't know about quilt, but crackle is not > original to POV-ray; it's one of a class of "cellular" functions. Hmmm... I guess I'll have to whip out my archived copy of the POV source again :) I'm going to cc this to the RAMA development list - we should probably start posting to the mailing list to get their help with this. I keep forgetting to do that... Peter. |
|
From: Michael D. <mi...@co...> - 2000-06-29 01:40:31
|
> In order for libtool to build a dll on windows, the dll must be built > using -no-undefined. Unfortunately, the dynamic extension library depends on > the ability to link in undefined symbols at run time. Every extension > library instantiates a class that adds the library information to a global > database. It doesn't have to do it this way, but at the time it seemed the > best way. I've had to add a couple hacks to get things to work right, so I'm > not particularly keen on keeping the current implementation. I'm thinking of > trying to use ltdl in the future, since it is designed to take care of these > types of problems. Have you used ltdl before? I haven't used that before I'm afraid, sounds a bit nasty. Downloaded Blender the other day to take a look at it... I have absolutely no idea what any of the buttons do, it's shocking :) All applications require tooltips on pain of death... Michael |
|
From: Peter S. <op...@in...> - 2000-06-27 00:49:33
|
----- Original Message ----- From: Michael Day <mi...@co...> To: Peter Stuart <op...@in...> Cc: RAMA - Development <ram...@li...> Sent: Sunday, June 25, 2000 10:50 PM Subject: Re: [Rama-devel] Re: texture generator > > > Novalis, are you interested in using RAMA for the extensensibility layer > of > > > this application? I'm pretty much done with both the static and dynamic > > > loaders. The dynamic loader has proven to be a pain to get to work on > > > windows, so the next release will only support dynamically loadable > > > extensions on linux. > > > > Hi Peter, > > > > what's causing the problem on Windows? There should be reasonable parity > > between dlopen / LoadLibrary, dlsym / GetProcAddress and so forth... > > > > Michael In order for libtool to build a dll on windows, the dll must be built using -no-undefined. Unfortunately, the dynamic extension library depends on the ability to link in undefined symbols at run time. Every extension library instantiates a class that adds the library information to a global database. It doesn't have to do it this way, but at the time it seemed the best way. I've had to add a couple hacks to get things to work right, so I'm not particularly keen on keeping the current implementation. I'm thinking of trying to use ltdl in the future, since it is designed to take care of these types of problems. Have you used ltdl before? Peter. |
|
From: Michael D. <mi...@co...> - 2000-06-26 04:58:44
|
> Novalis, are you interested in using RAMA for the extensensibility layer of > this application? I'm pretty much done with both the static and dynamic > loaders. The dynamic loader has proven to be a pain to get to work on > windows, so the next release will only support dynamically loadable > extensions on linux. Hi Peter, what's causing the problem on Windows? There should be reasonable parity between dlopen / LoadLibrary, dlsym / GetProcAddress and so forth... Michael |
|
From: Peter S. <op...@in...> - 2000-06-25 18:45:40
|
Hi, Hans. I hope you don't mind my forwarding this to the RAMA mailing list instead of replying to you directly. We may as well use the RAMA list since this is very applicable to its future development, and there isn't very much traffic on it. Also, I think Novalis is on this list too :) ----- Original Message ----- From: Hans Häggström <han...@he...> To: Peter Stuart <op...@in...> Sent: Sunday, June 25, 2000 12:14 PM Subject: Re: texture generator Hi Peter, >Sorry for being so unresponsive, I was just on a short vacation. No problem. :) >I have been rethinking the texture generator somewhat, >a procedural texture generator that uses matemathical functions >for the generation and modification of patterns seems better than >my initial bitmap filter based idea. It would allow arbitary zooming, >can be used to produce 3D textures, but could be a bit slower. >The DarkTree texture generator is a nice example of such a texture generator. >(http://www.darksim.com/html/darktree_textures.html) Hah! That's funny... this program is what I was thinking of from the beginning. I didn't realize we were talking about different things :) >Using this technique the different filters would be plugins (to allow new >filters to be easily created) and the texture generator itself would be a >plugin that could produce 2D or 3D textures from a texture description if the >proper filter plugins were loaded. The texture generator would probably >include a standard set of filter plugins, so that most textures could work >without need to find and download the required filters. >Novalis (no...@no...) has started on a texture generator in this >style, but I haven't tested the code yet. Novalis, are you interested in using RAMA for the extensensibility layer of this application? I'm pretty much done with both the static and dynamic loaders. The dynamic loader has proven to be a pain to get to work on windows, so the next release will only support dynamically loadable extensions on linux. Peter. |
|
From: Michael D. <mi...@co...> - 2000-06-05 13:30:13
|
> Hi, Mike. You mentioned a while ago some extensions to automike or autoconf > that would simplify RAMA's usage by C programmers. Have you made any > progress with this? I'd like to try and port my old GPCL program to RAMA, > and GPCL is written in straight C. Also, it would be nice if I could test > all of the new code I've added with a real C application. Thanks! Hi Peter, I'll have to get back to you on this one, as I'm afraid I'll be busy through June with uni exams. Sorry, Michael |
|
From: Peter S. <op...@in...> - 2000-05-26 19:26:16
|
Hi, Mike. You mentioned a while ago some extensions to automike or autoconf that would simplify RAMA's usage by C programmers. Have you made any progress with this? I'd like to try and port my old GPCL program to RAMA, and GPCL is written in straight C. Also, it would be nice if I could test all of the new code I've added with a real C application. Thanks! Peter. |
|
From: Michael D. <mi...@co...> - 2000-05-16 08:14:04
|
> Hi, Mike. I'm getting close to finishing the next release. I've encountered > a little problem, and was wondering if you happened to know of a solution. > When I statically link a library to one of the executables, certain symbols > aren't being linked, and I don't want to have to reference them in order to > get them to be included. I tried adding --whole-archive to the link line, > but they still aren't being added. The symbols do appear in the archive, > just not the final executable. Do you have any ideas? Would it help if I > sent you the code? Thanks. If the symbols are not referenced by anything, they won't end up in an executable that is linked with a static library. They will if you link with a shared object, though. It's a pain. Have you got global classes that you want to do something tricky with in the constructor? Michael |
|
From: Peter S. <op...@in...> - 2000-05-10 01:58:41
|
Hi, Mike. I'm getting close to finishing the next release. I've encountered a little problem, and was wondering if you happened to know of a solution. When I statically link a library to one of the executables, certain symbols aren't being linked, and I don't want to have to reference them in order to get them to be included. I tried adding --whole-archive to the link line, but they still aren't being added. The symbols do appear in the archive, just not the final executable. Do you have any ideas? Would it help if I sent you the code? Thanks. Peter. |