So sorry I haven't been updating! In between keeping up with school work and projects and Red Orchestra I just haven't had even thought about updating! My bad.
Basically I've just been catching up in schoolwork, lazing around for my little Thanksgiving break (way needed it!), and coding on my lil SFML thingy. I am not sure what it's going to be yet, possibly just a template codebase. I got an undo/redo system in and working for the most part - but wanna fine tune it and improve controls for the editor - otherwise the basics are almost all done! I tried implementing CEGUI, which I have done before, but I am thinking in one of the newer versions they changed a fundamental usage of it so I ran into some dumb issues when trying to integrate it with SFML - will have to return to that later..
There needs to be more US-based Red Orchestra servers, and more people need to play on them. I do fine with my pings as it is, but always playing with French/German/Russians get old - wish I was at least picking up on their languages better than I seem to be.. If you play let me know, it's such a fun game! Especially when there are lots of people in the server, it really gives a sensation unique to those sectors of World War II.
Sunday, November 29, 2009
Wednesday, November 18, 2009
Splines!
Sorry for not posting in so long. Went through a super heavy week, then schoolwork catchup, then reading. Anyway, I have returned to SFML and been doodling a little bit in various small projects I'm piecing together. I decided I should kill two birds with one stone and clear out more of my fixfox tabs (down to 71!) AND make a tech demo/proof of concept for myself on splines.
A while back I was reading up on them heavily, I didn't want to use a formula I didn't truly understand. I got them down great, and realized how awesome of an exercise they actually were in matrix maths!
That aside, I never actually DID anything with them. So I just whipped this up in about an hour and a half. It mainly took so long because I was trying different things with SFML's Shape system. I think in the end it came out pretty nice though! It currently supports Hermite, Cubic bezier, and Catmull-Rom splines. I would like to make it more interactive, so that one can simply drag the points around rather than just generating a new one and sliding about it. Probably should eat some supper now though, mmmmm. Beef stew to the rescue!
A while back I was reading up on them heavily, I didn't want to use a formula I didn't truly understand. I got them down great, and realized how awesome of an exercise they actually were in matrix maths!
That aside, I never actually DID anything with them. So I just whipped this up in about an hour and a half. It mainly took so long because I was trying different things with SFML's Shape system. I think in the end it came out pretty nice though! It currently supports Hermite, Cubic bezier, and Catmull-Rom splines. I would like to make it more interactive, so that one can simply drag the points around rather than just generating a new one and sliding about it. Probably should eat some supper now though, mmmmm. Beef stew to the rescue!
Tuesday, November 3, 2009
OpenMP + BSGP
Spent a large portion of my afternoon today reading over OpenMP and then BSGP, which stands for Bulk-Synchronous GPU Programming. Essentially it is attempting to do something similar to what OpenMP attempts to do for concurrency to the GPU arena. By this, I mean it is for general purpose programming on GPUs, and it attempts to also be quasi-cross-compatible across different manufacturer's cards. As it is CUDA et al. is fine, but they are all limited to their respective manufacturer's cards only. BSGP takes a similar-to-C-syntax blurb as a kernel function for a large number of stream based processors to run in parallel (way more than just 2 or 4 cores - but they are only good at certain things as compared to a CPU).
Pretty interesting stuff, I hope to apply OpenMP to my projects in the future especially! Beware jumping straight into it though - I think the guide that I have linked to does a fairly good job of catching you up on it but ANY multi-threaded programming will benefit from a thorough understanding of the intricacies and difficulties-by-nature of concurrency/parallelization.
Pretty interesting stuff, I hope to apply OpenMP to my projects in the future especially! Beware jumping straight into it though - I think the guide that I have linked to does a fairly good job of catching you up on it but ANY multi-threaded programming will benefit from a thorough understanding of the intricacies and difficulties-by-nature of concurrency/parallelization.
Monday, November 2, 2009
Fast PictureBox/Graphics Context Drawing (Manual Backbuffering) in C#
While I was working on my Lissajous Curves application, I ran into the issue of re-draw. I was using Visual Studio 2008, .NET 3.5, and everything was going fine except for the refresh rate on the picturebox. It was rather unacceptable. Keep in mind that my very first step had already been to check the Backbuffered property on the Form to true. One would think that it would show similar gains as any traditional backbuffering implementation would, but on the contrary I found no real benefit to the flag. It ended up that manually backbuffering was faster, so I present my implementation.
There are probably other ways to go about this, but this is the fastest I have come across so far. It's rather simple and is just the backbuffering process word for word basically. Instead of drawing straight to our target, we will have two targets, and one we show while we draw on the other. When we finish drawing, we switch out the targets and begin drawing on the one they WERE seeing, and repeat.
If you are doing any serious kind of computer graphics work then you should probably already be familiar with this concept, so I will stop elaborating on it. On to the important bits!
First, I presume you use CreateGraphics(), probably on the component you wish to issue draw commands to. You then use your received context's DrawEllipse() or what have you to draw on it.
All we do differently now, is we are going hold two graphical contexts and one bitmap.
In your declaration, or in the function, or whatever you are currently using, you probably have something as described above, like:
We will be replacing this, as described above, with:
Now, in your form's _Load() function, where you should have something along the lines of:
We will now add to this and expand it to: (note pictureboxContext remains, so of course match the names to fit - just incase you're not paying attention ;P)
Now, instead of drawing to our picturebox's Context, we will be drawing to the backbuffer's. When we are finished drawing onto the backbufferContext ( e.g. backbufferContext.DrawEllipse(...) ) and want to display our new buffer, we will need to blit it out to the picturebox's context. We can easily do this using the Graphic's class's DrawImage function:
There is nothing special about this, and I honestly feel that this is what the Backbuffered flag should have been doing behind the scenes all along, but oh well. I found this useful enough of a discovery to back-propogate it to my internship's C# terrain editor's display. So I hope someone else out there finds it useful :o)
~Jasmine
There are probably other ways to go about this, but this is the fastest I have come across so far. It's rather simple and is just the backbuffering process word for word basically. Instead of drawing straight to our target, we will have two targets, and one we show while we draw on the other. When we finish drawing, we switch out the targets and begin drawing on the one they WERE seeing, and repeat.
If you are doing any serious kind of computer graphics work then you should probably already be familiar with this concept, so I will stop elaborating on it. On to the important bits!
First, I presume you use CreateGraphics(), probably on the component you wish to issue draw commands to. You then use your received context's DrawEllipse() or what have you to draw on it.
All we do differently now, is we are going hold two graphical contexts and one bitmap.
In your declaration, or in the function, or whatever you are currently using, you probably have something as described above, like:
Graphics pictureboxContext;
We will be replacing this, as described above, with:
Bitmap backbuffer;
Graphics backbufferContext;
Graphics pictureboxContext;
Now, in your form's _Load() function, where you should have something along the lines of:
pictureboxContext = picturebox1.CreateGraphics();
We will now add to this and expand it to: (note pictureboxContext remains, so of course match the names to fit - just incase you're not paying attention ;P)
backbuffer = new Bitmap(pictureBox1.Width, pictureBox1.Height);
backbufferContext = Graphics.FromImage(backbuffer);
pictureboxContext = pictureBox1.CreateGraphics();
Now, instead of drawing to our picturebox's Context, we will be drawing to the backbuffer's. When we are finished drawing onto the backbufferContext ( e.g. backbufferContext.DrawEllipse(...) ) and want to display our new buffer, we will need to blit it out to the picturebox's context. We can easily do this using the Graphic's class's DrawImage function:
pictureboxContext.DrawImage(backbuffer, 0, 0);
There is nothing special about this, and I honestly feel that this is what the Backbuffered flag should have been doing behind the scenes all along, but oh well. I found this useful enough of a discovery to back-propogate it to my internship's C# terrain editor's display. So I hope someone else out there finds it useful :o)
~Jasmine
Friday, October 30, 2009
Visual Studio 2010
Soo I have some time before class and was going to give VS2010 a spin. Reading the What's New was awesome, static_asserts for C++ sound great, concurrency system, hooray! I had also heard they gave C++ a GUI editor much like VB/C#'s. Well, I tried creating a New Project, of Win32 calibre, with default settings (not empty project), and upon compilation with no changes...errors.
Boo! So next I tried Console with empty project. Well, same error. Link.exe exits with code 1.
Apparently in Microsoft.Cpp.Win32.Targets this is the offending line:
Not enough time before class to mess with it, so whatever. Otherwise things seem pretty nice, typing the little bit I did in the new editor with its anti-aliased text and whatnot was nice, although I remember reading that Intellisense is missing out on lots of normal features in this edition of C++, at least for now? Wonder if Visual Assist X will put these back in.
Oh well, back to '08 for now.
Boo! So next I tried Console with empty project. Well, same error. Link.exe exits with code 1.
Apparently in Microsoft.Cpp.Win32.Targets this is the offending line:
Not enough time before class to mess with it, so whatever. Otherwise things seem pretty nice, typing the little bit I did in the new editor with its anti-aliased text and whatnot was nice, although I remember reading that Intellisense is missing out on lots of normal features in this edition of C++, at least for now? Wonder if Visual Assist X will put these back in.
Oh well, back to '08 for now.
Thursday, October 29, 2009
Curvy!
Thought I would update you, just added the Butterfly curve and Rose curves to my lil Curve plotting app :> Oh, and I forgot to include sources last time, they are at the bottom of this post after the pics.
Source Code (C#)
Source Code (C#)
Differentials Explained
So, in spirit of the last post - and because I shared this on facebook the other day and forgot to include it here, here is a wonderful video from the pre-WWII era explaining differentials! It's a wonderful video.
Richard Feynman - 'Fun to Imagine'
Just found an awesome video from the links section of betterexplained.com. It's Richard Feynman, who was a physicist. This is actually the last clip on Youtube of the film this is from (specifically note it's part TWO of the last clip). Link to the beginning is below clip. Hope you enjoy as much as I did!
Linksies
The beginning of 'Fun to Imagine' (above talk)
Betterexplained.com - This is an informative site. He breaks down a wipe variety of math topics into nice, easy to understand versions. I think much in the same vein as Feynman would encourage. "Learn right not rote." is their motto. The links section I linked to earlier in this post leads to his "Links" page, where people can submit things they found that fit in with this - it led me to this video.
Linksies
The beginning of 'Fun to Imagine' (above talk)
Betterexplained.com - This is an informative site. He breaks down a wipe variety of math topics into nice, easy to understand versions. I think much in the same vein as Feynman would encourage. "Learn right not rote." is their motto. The links section I linked to earlier in this post leads to his "Links" page, where people can submit things they found that fit in with this - it led me to this video.
Monday, October 26, 2009
Lissajous Curves
Well, the internships are going great! Got the fists in and animated, now we just need to touch up the animations and get 'em skinned and get better sounds. It's looking good though! I can't wait to get it playable, and to show you guys :o) I actually have a few in-house videos already but I'm not sure if it's ready for public release yet..but I do have something I can show!!
I was reading some thread on cymatics when this guy in the comments used the word Lissajous to describe sand movement. I googled this strange word and found no definition, but instead a Wolfram's and a
wikipedia mathematics page. Quite informative, but fairly heady. There was once a time when I would shy away from this, but this time I decided, "Hey, I want to make a program that utilizes these!" And so, I did.
Here is the result of a total of about two hours, I suggest you download it and play with it :) I hope the Dance mode works as smoothly on slower PCs as it does on mine..let me know what you think! It's fairly silly but was a great learning experience. Here's some pics to show it happened:
I am including a link to the Release .exe. It's written in C# and so will require the .NET 3.5 framework.
Click to download Lissajous Curves Win32 Binary
~Jasmine
I was reading some thread on cymatics when this guy in the comments used the word Lissajous to describe sand movement. I googled this strange word and found no definition, but instead a Wolfram's and a
wikipedia mathematics page. Quite informative, but fairly heady. There was once a time when I would shy away from this, but this time I decided, "Hey, I want to make a program that utilizes these!" And so, I did.
Here is the result of a total of about two hours, I suggest you download it and play with it :) I hope the Dance mode works as smoothly on slower PCs as it does on mine..let me know what you think! It's fairly silly but was a great learning experience. Here's some pics to show it happened:
I am including a link to the Release .exe. It's written in C# and so will require the .NET 3.5 framework.
Click to download Lissajous Curves Win32 Binary
~Jasmine
Thursday, October 15, 2009
SIO2
Well, had a meeting today for my iPhone internship and we are currently undergoing a test checkout of SIO2, an iPhone game engine. It actually looks pretty sweet so far, it's very close to how I would currently design a game engine which is good: it utilizes Bullet, an open source physics system, it also of course utilizes the OpenAL/OpenGL ES already on the phone. At first I was rather wary about throwing out all the Quake 3 engine work we've done because I think we really are close to the ball starting to roll downhill rather than up, but oh well, what can you do. There are definitely big pros and big cons to both choices. We'll see how this thing does.
I can't say I'm not excited though. I'm getting my little schoolgirl squeal excitement about playing with this thing as I go through the videos - I've been itching to start up with Ogre again recently (was actually gonna post a thing about it actually) and on the forums I read that the current version utilizes an Ogre scene graph-inspired layout! It's almost like a nice refreshing dream come true. Built specifically FOR the iPhone, open source (I think? sort of? At least there are user patches on the forums for some thing (faster PNG loading in particular)), fairly sexy, etc... But it's not Quake 3. :~(
I really would like to develop on Quake 3, and I really would like to explore SIO2. I'm not sure about estimation for time frame with SIO2 though, but I guess when all is said my answer I don't care either way. Hell, I'd like to do them both if we had time and energy to spare lol
spoon!
I can't say I'm not excited though. I'm getting my little schoolgirl squeal excitement about playing with this thing as I go through the videos - I've been itching to start up with Ogre again recently (was actually gonna post a thing about it actually) and on the forums I read that the current version utilizes an Ogre scene graph-inspired layout! It's almost like a nice refreshing dream come true. Built specifically FOR the iPhone, open source (I think? sort of? At least there are user patches on the forums for some thing (faster PNG loading in particular)), fairly sexy, etc... But it's not Quake 3. :~(
I really would like to develop on Quake 3, and I really would like to explore SIO2. I'm not sure about estimation for time frame with SIO2 though, but I guess when all is said my answer I don't care either way. Hell, I'd like to do them both if we had time and energy to spare lol
spoon!
Wednesday, October 14, 2009
Website Updates
Well, I implemented multithreading into the terrain editor, and then it hit me at the very end that while it all does work as expected, the entire algorithm itself suffers from its own race condition. Particle deposition sort of relies on iteratively working the environment, and as far as I can tell at the moment, there is no real good way to split this task up other than just doing it.
This means optimizations could be made in the current search range, I bet there's a lot of unnecessary overlap that could be removed. At the end of the day though, it's a tool and it's forming the map, so speed is not that big of a concern. Besides, it's pretty damn fast as it is as long as the particle range threshold isn't set ridiculously high.
In other news, added a soundcloud widget to me website and worked on a bit of music. Today feels kind of like a bust because I did all this research into implementing multi threading well and then it ends up my fear came true and I can't even use it with my central algorithms! Haha. But more important: now what to read. >_< Soo many freaking tabs man, will I ever get through them all!?
This means optimizations could be made in the current search range, I bet there's a lot of unnecessary overlap that could be removed. At the end of the day though, it's a tool and it's forming the map, so speed is not that big of a concern. Besides, it's pretty damn fast as it is as long as the particle range threshold isn't set ridiculously high.
In other news, added a soundcloud widget to me website and worked on a bit of music. Today feels kind of like a bust because I did all this research into implementing multi threading well and then it ends up my fear came true and I can't even use it with my central algorithms! Haha. But more important: now what to read. >_< Soo many freaking tabs man, will I ever get through them all!?
Tuesday, October 13, 2009
Momentary Lapse
Well I apologize, I actually had a portion of a post typed out and saved in notepad, but have since for some reason deleted it. I have been rather busy with my internships this past weekend, but in my spare time I have mainly been reading and learning new things.
I learned splines/curves, which are pretty neat. You essentially pass a set of points and get the curve that approximates or fits between the middle two with the outer two as weights. I want to play with this in an implementation and write an article on it if I can find the time.
I also found a nice programming slideshow/video from ASM '09, which essentially broke down the current state of things as far as graphics game programming. It was given by a the lead engineer from the Unity team and in essence for any of my future projects I am pretty sure I am going to skip along with Ogre. This will simultaneously allow OpenGL as well as DirectX, and just generally be more agreeable with the things I tend to do. Namely the scene graph and everything, I'm to the point where I'm just creating my own, which is fine, but I'd rather stop re-inventing the wheel at this point - my rate of learning versus grinding is quickly going out of proportion for the time being.
Anyway, that's what my old post was going to be about, but since then I've been reading a lot more and it all kind of blurs as I've read SO much. I've come down with a cold so I've had time to just 'stare read' to pass the time. I really am going to try and take more 'blog breaks' in between readings to help disseminate things and hopefully share more indepth summaries or something of articles; as a bonus it would help my retention. Today for example I've been grooming through More Effective C# (awesome book, btw), specifically the Multi-threading section as it pertains to the tool that I am considering making multi-threaded for my internship. It was a great read, but I should have paused there. The next section, on collections and generics/actions/predicates/lambdas, ALL also (at least sort of could) apply to the things I'm doing, so I read those too. There's just no way I can be retaining everything from these articles by reading them like an addicted magazine reader. At least it's better than reading some magazine telling me I'm fat, haha.
I hope to go through the best ones and put them out in code, cementing my grasp of the concepts they cover. Regardless, I've been doing good about staying focused and really devoting my attention to what I'm reading - it's almost Zen like in a way, so at least that's something.
Sorry for this post lacking in any real content, just wanted to let you know I haven't forgotten about this thing :o)
I learned splines/curves, which are pretty neat. You essentially pass a set of points and get the curve that approximates or fits between the middle two with the outer two as weights. I want to play with this in an implementation and write an article on it if I can find the time.
I also found a nice programming slideshow/video from ASM '09, which essentially broke down the current state of things as far as graphics game programming. It was given by a the lead engineer from the Unity team and in essence for any of my future projects I am pretty sure I am going to skip along with Ogre. This will simultaneously allow OpenGL as well as DirectX, and just generally be more agreeable with the things I tend to do. Namely the scene graph and everything, I'm to the point where I'm just creating my own, which is fine, but I'd rather stop re-inventing the wheel at this point - my rate of learning versus grinding is quickly going out of proportion for the time being.
Anyway, that's what my old post was going to be about, but since then I've been reading a lot more and it all kind of blurs as I've read SO much. I've come down with a cold so I've had time to just 'stare read' to pass the time. I really am going to try and take more 'blog breaks' in between readings to help disseminate things and hopefully share more indepth summaries or something of articles; as a bonus it would help my retention. Today for example I've been grooming through More Effective C# (awesome book, btw), specifically the Multi-threading section as it pertains to the tool that I am considering making multi-threaded for my internship. It was a great read, but I should have paused there. The next section, on collections and generics/actions/predicates/lambdas, ALL also (at least sort of could) apply to the things I'm doing, so I read those too. There's just no way I can be retaining everything from these articles by reading them like an addicted magazine reader. At least it's better than reading some magazine telling me I'm fat, haha.
I hope to go through the best ones and put them out in code, cementing my grasp of the concepts they cover. Regardless, I've been doing good about staying focused and really devoting my attention to what I'm reading - it's almost Zen like in a way, so at least that's something.
Sorry for this post lacking in any real content, just wanted to let you know I haven't forgotten about this thing :o)
Saturday, October 3, 2009
Heightmaps!
Okay, so last night before I went to bed I built from scratch a new heightmap system utilizing SFML and OpenGL this time. I am happy to wave goodbye to SDL! I implemented OpenGL's Select mode Picking system and had to debug it for a while for a stupid perspective FOV mismatch. Soon after I confirmed that it would not suit my purposes and then came across that it's going to be phased out in OGL 3.0 anyway as its not actually 3d graphics related. So I ripped out all the select mode picking code and put in a transposition system.
In essence, you are reversing the normal matrix transformations (from space->model->world->clip->screen to screen->clip->world->model->space (that's simplified, there's a few more steps inbetween). For those of you who don't understand any of that, it basically turns a 3 dimensional coordinate (x, y, z) into a 2 dimensional screen coordinate or vice versa. In reality they are 3 dimensional screen coordinates with the z being the top of the depth buffer or 0..1 for near and far planes respectively. Now I can tell exactly where in the world the user is clicking, and it even has a cute side effect where when I create a box where you are clicking in the world, if one holds the mouse button down, then you are now clicking on the edge of the newly created box, so it moves to there, but now you are clicking on the edge of where it just moved, so it moves closer, and closer, and closer, and smacks the screen in the face. It's kind of funny, albeit unexpected at first. I am thinking if I disable writing to the depth buffer when I draw it that should fix that issue as my select code is using the depth buffer to determine where in the near/far clip planes the user is clicking (it thus picks the closest).
Anyway, now I have a terrain mesh that has a cursor and allows raising and lowering. I have some issue somewhere in the renderer though that is causing strange (albeit cool looking) circular artifacts when you edit the mesh. When you raise a lump, it actually raises a LOT of lumps. I was too sleepy to correct this so I decided it would be best to take a break.
I then started reading over the docs for Bullet physics again. Pondering on how I want to implement things, and even where I want to take this. So I decided to sleep on it.
Actually I lied, I played Aion for a few hours and THEN went to sleep. Anyway, I ended up dreaming about programming! Woke up pondering a few things. Now I am just stopping reading back over Ogre3d. Exciting news there!! The next version will use the MIT license, which will loosen licensing requirements with Ogre even further! The Google Summer of Code 2009 also evidently resulted in someone totally revamping the samples. I am not sure if these new and improved samples are in the Ogre distribution yet, but they are accessible (at least the one I've been looking over) in the Ogre Wiki. It's about time too, some of those samples were ....
So in all of this, I found on the Ogre forums someone has written a terrain manager. I haven't looked at its code yet but have been perusing the monolithic thread that it started from. It now has its own forum section, but if that link works correctly you should see where the author is pondering changes for his next version and he mentions some shortcomings with the current design.
Anyway, so now I'm at the point where I'm trying to determine if I should stay the path or just return home to Ogre. If I stay where I am at, I can continue doing interesting things, but it will be all on my own with straight OpenGL. I can also learn from the other managers, etc... This will allow me to really support anything, my next steps anyway were to add in some basic LOD and eventually paging once I got textures working nicely. While the custom Ogre terrain manager cannot support paging or LOD in its current state (although the Ogre scene manager might/should(?) handle the LOD business anyway. There is also a 3rd iteration of the slowly developing paging system for it too. It already can splat textures and do some other nifty things though.
So I'm just not sure. It's one of those could go either way things, the pros and cons are fairly convoluted in this one. I suppose I could even take the Ogre heightmap code and just take a stake to it and turn it into some hybrid mixture. I suppose I should eat, about four hours overdue from lunch and had no breakfast and ate shitty junk food last night. Afterwards I have actual internship and school work beckoning, as well as a required legion event on Aion. But in reality, I will probably just keep perusing the forums and reading up on everything. Knowledge is power.
In essence, you are reversing the normal matrix transformations (from space->model->world->clip->screen to screen->clip->world->model->space (that's simplified, there's a few more steps inbetween). For those of you who don't understand any of that, it basically turns a 3 dimensional coordinate (x, y, z) into a 2 dimensional screen coordinate or vice versa. In reality they are 3 dimensional screen coordinates with the z being the top of the depth buffer or 0..1 for near and far planes respectively. Now I can tell exactly where in the world the user is clicking, and it even has a cute side effect where when I create a box where you are clicking in the world, if one holds the mouse button down, then you are now clicking on the edge of the newly created box, so it moves to there, but now you are clicking on the edge of where it just moved, so it moves closer, and closer, and closer, and smacks the screen in the face. It's kind of funny, albeit unexpected at first. I am thinking if I disable writing to the depth buffer when I draw it that should fix that issue as my select code is using the depth buffer to determine where in the near/far clip planes the user is clicking (it thus picks the closest).
Anyway, now I have a terrain mesh that has a cursor and allows raising and lowering. I have some issue somewhere in the renderer though that is causing strange (albeit cool looking) circular artifacts when you edit the mesh. When you raise a lump, it actually raises a LOT of lumps. I was too sleepy to correct this so I decided it would be best to take a break.
I then started reading over the docs for Bullet physics again. Pondering on how I want to implement things, and even where I want to take this. So I decided to sleep on it.
Actually I lied, I played Aion for a few hours and THEN went to sleep. Anyway, I ended up dreaming about programming! Woke up pondering a few things. Now I am just stopping reading back over Ogre3d. Exciting news there!! The next version will use the MIT license, which will loosen licensing requirements with Ogre even further! The Google Summer of Code 2009 also evidently resulted in someone totally revamping the samples. I am not sure if these new and improved samples are in the Ogre distribution yet, but they are accessible (at least the one I've been looking over) in the Ogre Wiki. It's about time too, some of those samples were ....
So in all of this, I found on the Ogre forums someone has written a terrain manager. I haven't looked at its code yet but have been perusing the monolithic thread that it started from. It now has its own forum section, but if that link works correctly you should see where the author is pondering changes for his next version and he mentions some shortcomings with the current design.
Anyway, so now I'm at the point where I'm trying to determine if I should stay the path or just return home to Ogre. If I stay where I am at, I can continue doing interesting things, but it will be all on my own with straight OpenGL. I can also learn from the other managers, etc... This will allow me to really support anything, my next steps anyway were to add in some basic LOD and eventually paging once I got textures working nicely. While the custom Ogre terrain manager cannot support paging or LOD in its current state (although the Ogre scene manager might/should(?) handle the LOD business anyway. There is also a 3rd iteration of the slowly developing paging system for it too. It already can splat textures and do some other nifty things though.
So I'm just not sure. It's one of those could go either way things, the pros and cons are fairly convoluted in this one. I suppose I could even take the Ogre heightmap code and just take a stake to it and turn it into some hybrid mixture. I suppose I should eat, about four hours overdue from lunch and had no breakfast and ate shitty junk food last night. Afterwards I have actual internship and school work beckoning, as well as a required legion event on Aion. But in reality, I will probably just keep perusing the forums and reading up on everything. Knowledge is power.
Subscribe to:
Posts (Atom)