User Functions
Don't have an account yet? Sign up as a New User
Lost your password?
Events
There are no upcoming events
|
 |
| Author: |
|
| Dated: |
Saturday, July 18 2009 @ 02:15 AM NZST |
| Viewed: |
186 times |
|
My volumetric renderer (technically, distance field renderer) has been sitting stagnant for a long time. Largely because I had several headaches getting sphere subtraction going with the sparse volume, so I felt stupid, and it seemed like it had been much surpassed already (already being after ~5 years of intermittent development ;-). Anyway, I recently got motivated to come back to it and progress has been surprisingly easy! I'll start with the pictures, everyone likes pictures.
 
The left image shows the brand new ability to subtract cubes from the environment. Works surprisingly well considering sharp edges can't be represented perfectly and are the achilles heel of the poor renderer. The right image shows how I've made the environment as a whole more complex, which I couldn't do before (see technical details). Also, it shows how a 2048^3 volume is still astoundingly massive. In the centre of the image you might see some little marks on one of the surfaces. Those are the same cubes shown in the left image.
So, technical details...
|
| Author: |
|
| Dated: |
Wednesday, July 15 2009 @ 12:56 AM NZST |
| Viewed: |
114 times |
|
 So in one of the logging articles, boost::thread_specific_ptr was mentioned. In my opinion, it is a very cool little thing. It's basically just a pointer which can have a different value in each thread. Why would you want one? Well, I used to have a bit of a problem. Angel script, the scripting language I use, requires a thing called a context when calling script functions. Contexts cannot be shared between threads and I wanted to cache the context between calls to the scripting language, since creating them is relatively expensive. Calls are made by a couple of different threads, so caching the context required a bit of hackery. A thread specific pointer, however, is a perfect fit. For each call to script I check if the context for the thread is null (unlike a normal pointer it is initialised to null by default) and if it is I create the context. Otherwise I just use the one already cached for this thread.
Also, this is what my log files look like now:
Log file
They're quite colourful. Completely overkill, too. But the really great thing is that I'm now happy to look at log files. I want the program to go up in flames just so I have an excuse to read their christmasy goodness! Though I suppose the novelty will wear off. 2 comments
Most Recent Post: 07/20 05:15PM by Razor
|
| Author: |
|
| Dated: |
Monday, July 13 2009 @ 03:15 AM NZST |
| Viewed: |
75 times |
|
 So I've just been writing a contender for the most overkill logging system known to man. You see, with my "spare time" projects, I have a tendency to not do anything that doesn't stretch my programming muscles a bit. It's great to do something tricky after watching your skills atrophy for an entire semester. So, when I decide it's time to replace all my cout logging with something a bit tidier, it's not enough to just write them to a file. That would be boring. The task has to become complicated enough to retain my interest.
With that in mind, I based my solution on two articles: Using XML Technologies For Enhancing Log Files and Simple STL Logging System (which is basically about boost streams). By combining these, I end up with an xml logging system which is written to like a standard stream. It's a macro, admittedly, but there's nothing you can do about that while keeping file/function/line information. I have yet to do the xslt part, but most of it is in place, in a rough form.
Along the way, I came up with the idea of a logged exception. A logged exception is basically just a shortcut for logging an error, then throwing an exception, and using the same message for both. This allows the calling code to catch and handle the exception if it wants, but if it is not handled or handled badly then you still have a handy message in the log so you know where things went wrong.
|
| Author: |
|
| Dated: |
Saturday, May 02 2009 @ 01:54 PM NZST |
| Viewed: |
134 times |
|
On Wednesday, I took part in the imagine cup NZ finals. I was technically team lead of PigeonGrape Productions, a team consisting of three other 3rd year software engineers: Shrikkanth Sreedharan, Jonathan Smith and Sutirtha Basak. I say technically because I think I pioneered a new leadership style: Lead by following*. Our industry mentor was Roger Ford of Innovise. To be perfectly honest, we didn't expect to make it to the finals, but the first round judges must have seen something they liked in our presentation. I have a feeling that, as much as anything, we made them laugh after a long day. In any case, we were one of the 6 teams that got into the New Zealand finals. So, we had to present in front of nearly 600 people. Which we did, wearing suits no less. We didn't place in the top 3, but did really step it up a notch for the finals. I think we can be proud of what we achieved, and we were crowd favourites (we made people laugh).
Our idea started off as a game for teaching physics, and gradually morphed into a play oriented teaching system based on community content and problem visualisation. In other words, we learnt how to talk things up. I might update this once there are some photos from the event.
* Believe it or not, there are actually advantages to "Lead by following". Everyone felt I was someone they could talk to about the project, be it good or bad. Even when team members hated each other, I would hear it from both sides. And I could usually get my way without people really noticing, if I actually wanted to. But most of the time I didn't. 1 comments
Most Recent Post: 05/21 03:06PM by BlindSide
|
| Author: |
|
| Dated: |
Thursday, April 09 2009 @ 11:04 PM NZST |
| Viewed: |
121 times |
|
| Author: |
|
| Dated: |
Friday, January 02 2009 @ 11:08 PM NZDT |
| Viewed: |
149 times |
|
So I came back to my voxel renderer, played around with it a bit and had a hunch. I changed a 1 to a 2 and tada, sphere subtraction fixed! I haven't bothered to figure out exactly why, and maybe I never will. It currently doesn't keep the radii optimal or free any nodes that are no longer needed, so the more spheres you subtract the slower and more memory hungry it gets. But it looks right, and for minimal thinking and 0 effort, that's not bad!
|
| Author: |
|
| Dated: |
Sunday, December 07 2008 @ 06:19 PM NZDT |
| Viewed: |
152 times |
|
I've got normal vectors calculated in my voxel renderer again, and I'm working on the real-time sphere subtraction. The fact that it's a sparse volume makes that quite tricky. Rather than my typical hammering on the keyboard like a monkey until it works, I'm going to have to sit down and figure it out properly. But not right now. Right now, I'm going to show off some pictures.

This one is intended to convey that a 2048^3 volume is still freakin huge!

This one shows how sphere subtraction is still broken. Sadly.
|
| Author: |
|
| Dated: |
Saturday, December 06 2008 @ 11:50 PM NZDT |
| Viewed: |
187 times |
|
 I've had another attempt at sparse volumes for my voxel-like renderer. A bit late though, I've been thoroughly beaten to it. Not that surprising, considering how many years I've been chipping away at it (and, lately, just plain neglecting it).
This sparse volume is much simpler than previous attempts, and as such, works quite a bit better. I've got a 2048^3 volume working, with floating point radii, and it's taking around a gig of ram. And let me say this: You have no idea how big a 2048^3 volume is. Here's a picture:
You see each of the little squares on the left? They're 8 grid points across. Each 8^3 bunch of radii is coloured like a colour cube. There are artifacts, but I don't care at the moment. I'm tired. 2 comments
Most Recent Post: 12/10 09:25AM by Razor
|
| Author: |
|
| Dated: |
Sunday, November 02 2008 @ 12:16 AM NZDT |
| Viewed: |
343 times |
|
 So I've been thinking (boom). Not about the exam on Monday, no way that would happen. I've been thinking about how quite a few people live out of a USB memory stick/drive/key/dongle/whatever, especially at uni. Some people do it because they don't have a laptop and use a combination of lab and home computers. Some people do it even though they do have a laptop. For example me. To the point where I want to get a fancy shmancy memory card thingy that can still be used with USB, so I don't have an 8gb stick hanging off the side of my laptop all the time.
Money sinks aside, I see this sort of portable storage playing a big role in the near future of computing. It already is, you say? Yes, well, that's what tipped me off. But seriously, it's pretty limited at the moment. Most people don't put that many programs on their USB whatchamacallits. The reason for this, from what I've seen, is that a lot of programs just don't handle it very well. E.g. they use the registry (eww) or store stuff in your user or system directories that don't move when the program does. There's been some effort to sort this out, and half-assed operating system support for this kind of thing, but I ignored it all because it would take per-program effort. It seems to me the problem is being solved at the wrong level entirely.
The clean solution is to have an operating system on your USB, along with your user profile and so on, as a portable OS. Details after the break.
|
| Author: |
|
| Dated: |
Tuesday, October 14 2008 @ 12:10 AM NZDT |
| Viewed: |
190 times |
|
I figured out how to set up a subversion repository on my web host today. It was a bit tricky, because I use shared hosting which has no provisions for svn whatsoever. However, it turns out that ssh access to your server is all you really need to set it up. Host Monster does provide ssh access if you send them a photo of some ID, so it was all good.
|
First | Previous | 1 2 3 4 5 6 7 8 9 10 | Next | Last |
 |
Who's OnlineGuest Users: 6
Get Firefox
|