| --- Log opened Fri Sep 30 00:00:24 2011 |
| 00:22 | | Vornicus-Latens is now known as Vornicus |
| 00:26 | | Derakon[AFK] is now known as Derakon |
| 01:10 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 01:32 | | Attilla [Some.Dude@Nightstar-f29f718d.cable.virginmedia.com] has quit [Ping timeout: 121 seconds] |
| 01:54 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has joined #code |
| 01:56 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [[NS] Quit: Well, most things get better when I kick them!] |
| 02:05 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| 02:30 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [Client closed the connection] |
| 02:30 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| 02:32 | | gnolam [lenin@Nightstar-202a5047.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 02:36 | | cpux|2 [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| 02:38 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 02:38 | | cpux|2 is now known as cpux |
| 02:51 | | Kindamoody[zZz] is now known as Kindamoody |
| 03:18 | < Phox> | So, does anyone have any experience with Sage math, in here? |
| 03:20 | < Vornicus> | "Sage" math? |
| 03:21 | < Phox> | http://en.wikipedia.org/wiki/Sage_%28mathematics_software%29 |
| 03:22 | < Phox> | Just wondering if it's as capable as some of the other software packages like matlab |
| 03:22 | < Vornicus> | I've never used it, but it looks like something I should look into |
| 03:23 | < Phox> | Yeah. My math prof was recommending it. |
| 03:53 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [[NS] Quit: Well, most things get better when I kick them!] |
| 04:01 | | Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Client exited] |
| 04:03 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| 04:05 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has joined #code |
| 04:20 | < celticminstrel> | Whee, it lets me draw filled and outlined rectangles and circles in any colour! I guess the next step is selecting objects. |
| 04:23 | | cpux is now known as shade_of_cpux |
| 04:40 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 04:40 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 04:44 | < Derakon> | Making your own drawing program, CM? |
| 04:45 | < celticminstrel> | Yup. |
| 04:45 | < celticminstrel> | It's an assignment. |
| 04:49 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has quit [Client closed the connection] |
| 04:49 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has joined #code |
| 05:13 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 05:16 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has quit [Ping timeout: 121 seconds] |
| 05:30 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has joined #code |
| 05:34 | | kwsn is now known as kw-sleep-n |
| 05:36 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:14 | | kw-sleep-n [kwsn@Nightstar-635d16fc.org] has quit [Ping timeout: 121 seconds] |
| 06:15 | | kw-sleep-n [kwsn@Nightstar-635d16fc.org] has joined #code |
| 06:33 | | Derakon is now known as Derakon[AFK] |
| 06:42 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has quit [[NS] Quit: I <3Lovecraft<3 Vorn!] |
| 06:44 | | Janus [NSwebIRC@Nightstar-b1ac186a.res.rr.com] has joined #code |
| 07:07 | | Janus [NSwebIRC@Nightstar-b1ac186a.res.rr.com] has quit [[NS] Quit: a good nightszzz] |
| 10:03 | | Attilla [Some.Dude@Nightstar-f29f718d.cable.virginmedia.com] has joined #code |
| 10:12 | | Attilla [Some.Dude@Nightstar-f29f718d.cable.virginmedia.com] has quit [[NS] Quit: ] |
| 11:36 | | Kindamoody is now known as Kindamoody|out |
| 11:39 | | kw-sleep-n is now known as kwsn |
| 11:43 | | Attilla [Some.Dude@Nightstar-f29f718d.cable.virginmedia.com] has joined #code |
| 11:51 | | gnolam [lenin@Nightstar-202a5047.priv.bahnhof.se] has joined #code |
| 11:53 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [[NS] Quit: This computer has gone to sleep] |
| 11:56 | | AnnoDomini [annodomini@FFB3F3.4C5BE8.2014E2.DC0864] has joined #code |
| 12:02 | | shade_of_cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 12:28 | < gnolam> | http://i.imgur.com/zymdw.jpg |
| 12:51 | < TheWatcher> | ... that's bad |
| 12:51 | < AnnoDomini> | Groan. |
| 12:54 | | AnnoDomini [annodomini@FFB3F3.4C5BE8.2014E2.DC0864] has quit [[NS] Quit: Away! To glory!] |
| 13:09 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has joined #code |
| 13:33 | | Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds] |
| 13:37 | | Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code |
| 14:19 | | Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code |
| 14:37 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has joined #code |
| 15:55 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has quit [[NS] Quit: If the world didn't suck, we'd all fall off.] |
| 16:40 | < kwsn> | oh w.t.f. |
| 16:40 | | * kwsn head desks |
| 16:41 | < kwsn> | week of work just gone cause they way i was doing it won't work |
| 17:05 | < gnolam> | Congratumalations! |
| 17:15 | < Tarinaky> | Stupid question: |
| 17:15 | < Tarinaky> | In a perl sub each recursion has its own copy of local variables right? |
| 17:15 | < Tarinaky> | I mean, everything's on a function stack right? |
| 17:17 | < kwsn> | FUCK YEAH FOUND HOW TO MAKE THIS WORK |
| 17:17 | | * kwsn dances (her serial driver) |
| 17:20 | | * gnolam drops depth charges on Tarinaky's perl sub. |
| 17:34 | < TheWatcher> | Tarinaky: yes* |
| 17:35 | < Tarinaky> | Then why the fuck is it pushing stuff into this array twice. |
| 17:35 | < TheWatcher> | * except for simple identifiers used as filehandles. If you use real variables as filehandles, you're okay, but open(FOO, "bar") will bite you in the arse |
| 17:35 | < Tarinaky> | I've left the lab so I don't have the source with me now. |
| 17:50 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 17:54 | <@ToxicFrog> | Tarinaky: no remote access? |
| 18:07 | < Tarinaky> | Not atm. |
| 18:07 | < Tarinaky> | I think I can access the files by logging onto an ssh server and doing some sort of rain dance. |
| 18:07 | < Tarinaky> | But it doesn't -really- matter. |
| 18:22 | | Kindamoody|out is now known as Kindamoody |
| 18:49 | | Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Client exited] |
| 19:13 | <@ToxicFrog> | Tarinaky: so...you do have remote access, over SSH? |
| 19:25 | | Kindamoody is now known as Kindamoody[zZz] |
| 19:37 | <@ToxicFrog> | Tarinaky: if you're on linux, you can just mount the remote system as a networked drive, then |
| 19:51 | < Tarinaky> | The files aren't on the same server as the one I have ssh access to. |
| 19:52 | < Tarinaky> | Hence the need for some sort of raindance. |
| 20:00 | <@ToxicFrog> | Oh. |
| 20:26 | | Janus [NSwebIRC@Nightstar-b1ac186a.res.rr.com] has joined #code |
| 20:46 | < Janus> | Math. *sobsob* |
| 20:48 | < Janus> | I have no idea what this'd be called in math-ese. Or... how to even draw it, but what would a sideways pyramid thing like this be called? http://goo.gl/Z8Itq |
| 20:50 | < Vornicus> | VIEW FRUSTUM CULLING |
| 20:51 | < Vornicus> | Is the name of the technique you are looking for. |
| 20:51 | < Janus> | Oh, it has a name! Thanks! *jumps in the google TAKE OFF* |
| 20:54 | < Vornicus> | You might also enjoy backface culling, and Z order culling. |
| 20:56 | < Vornicus> | (backface culling: why, if you find yourself outside the level in a 3d game, you can see through the near walls of corridors.) |
| 20:56 | < Janus> | Oh, I think I got the backface one already! Not sure about the z-order-ing though |
| 20:58 | < Vornicus> | z order culling: things that are absolutely guaranteed to be behind other things should not be rendered. I'm not entirely sure how you can do that more efficiently than the video card can but if you get a report on how many fragments get rendered from a tri or rect, you can use that information to not render things that would be contained within a shape that would not get rendered anyway! |
| 20:59 | < Vornicus> | So in the minecraft case, you can (for instance) build a cuboid that surrounds a chunk, and then try rendering that cuboid, and if nothing would show up from that cuboid, you can just not render things in that chunk. |
| 20:59 | < Janus> | Oh, I see! |
| 21:00 | < Vornicus> | I do not know how much power you actually get in this form. |
| 21:03 | < Vornicus> | But that's vaguely how I'd do it in software. It seems like doing that in hardware might not work well. |
| 21:08 | < Janus> | The way I was gonna try, after... well, figuring out this frustum thingy. Was scanning row to row for any blocks with sides that both, face a non-opaque block and are facing towards the camera. Then adding it to the vertice list. The row starts at the highest point visible from the frustum, and goes down until it's below the frustum (I hope frustum's the right word) |
| 21:09 | < Vornicus> | Remember that if you're looking up high enough, the zenith is inside the frustum. |
| 21:09 | < Janus> | It kind of breaks down though if it's pointing in a weird direction... like 45 degrees up-- YEAH THAT |
| 21:09 | < Vornicus> | THis will play hell with your code. |
| 21:14 | < Janus> | I guess I could check if it reaches beyond the zenith. If it does, it could maybe... hrm. Make an axis aligned bounding box that contains the frustum, and render that. It wouldn't be too much wasted rendering, since there's not much geometry that could be vertical of you, as opposed to looking at the horizon |
| 21:14 | < Vornicus> | Note: you may be better off baking your chunk data regardless of frustum |
| 21:14 | < Vornicus> | And then changing it only on chunk updates |
| 21:17 | < Vornicus> | Because you're looking at (using Minecraft's numbers) 200k checks to build your render list for a single chunk. |
| 21:18 | < Janus> | I gave that a try, using only an indice VBO thing to specify what to render, but it got pretty overwhelming... It was hard enough compressing the block data itself, and it's only 12 bytes per block, aha. I wouldn't know how to compress vertice data without having to rebuild the list whenever the player moves or does anything |
| 21:19 | < Vornicus> | 12 bytes per block |
| 21:19 | < Vornicus> | That seems high; minecraft uses, um. two and a half. |
| 21:20 | < Vornicus> | (plus some variety of extra blobs for things like signs and stuff. |
| 21:20 | < Janus> | 1 byte is for the type, 1 is for misc data, 2 is for referencing an external list (for chests and the like), and the remaining 8 are used for sub voxels, 4x4x4 per block. The compression thing I used takes that cost away though for things that don't use it |
| 21:21 | < Vornicus> | How big are your chunks? |
| 21:21 | < Janus> | 64x64x256 |
| 21:21 | < Janus> | Well, 128 tall, but it's two chunks, one on top of the other |
| 21:22 | < Vornicus> | Oh they're not small at all. Okay, so those 200k checks per chunk are now, um. 3 million. |
| 21:22 | < Janus> | The compression is, basically, if a block is a duplicate of one above it, it keeps data for only the one above it. If the top is air and it goes down 84 meters, it's still only one air block |
| 21:23 | < Vornicus> | RLE, hm? |
| 21:23 | < Vornicus> | Note: compression is what you use to keep stuff small on disk. |
| 21:23 | < Janus> | There's a 128bit bitset that keeps track of every row. Getting a block from the row is basically block[bitset.hammingweight(z)] |
| 21:24 | < Janus> | RLE? |
| 21:24 | < Vornicus> | Run-Length Encoding |
| 21:24 | < Janus> | Oh! I suppose it is! |
| 21:24 | < Vornicus> | Ok. Hamming weight is kind of expensive too. |
| 21:25 | < Vornicus> | Okay, I'm going to recommend the following. |
| 21:25 | < Janus> | It has the weakness of, well, once you change an element, the list permanently expands, and doesn't contract. Unless you save and load. Oh, I should show you the hamming thing I'm using! |
| 21:25 | < Vornicus> | Don't keep your chunk compressed while you're looking at it. |
| 21:25 | < Vornicus> | RAM is for this task a fuckton cheaper than time. |
| 21:26 | < Janus> | That's true... |
| 21:26 | < Vornicus> | But in the same breadth |
| 21:26 | < Vornicus> | breath* |
| 21:27 | < Vornicus> | Here are things that you actually need for a chunk you're not in |
| 21:27 | < Vornicus> | 1. the render list. 2. the collision list. |
| 21:28 | < Janus> | ... oh yeaaah, physics! |
| 21:28 | < Vornicus> | If nothing is /happening/ in a chunk, then the chunk doesn't need to have its full data loaded |
| 21:29 | < Janus> | It gets kind of scary whenever I get a calculator out and get the cost of it though... |
| 21:30 | < Vornicus> | Yes well. |
| 21:31 | < Janus> | (the bitset/hamming thing if you wanted to see. I adapted some bit twiddle I found for 32bit things and expanded it to... well, 4 32bit things. http://pastebin.starforge.co.uk/480 ) |
| 21:35 | < Vornicus> | That is rather a lot of code, unfortunately |
| 21:35 | < Janus> | I guess, if I only keep the 81 most surrounding chunks loaded, the base cost is only 243ish mb |
| 21:36 | < Vornicus> | That's still more than you probably want! |
| 21:36 | < Janus> | Yeah... when I was debugging it, it took a while to do 500,000 tests. Well, longer than a second anyway. |
| 21:37 | < Vornicus> | Yeah. You don't have that kind of time. |
| 21:37 | < Vornicus> | Note: at this size, 81 chunks is about, um |
| 21:38 | < Janus> | 9x9 around you, so 4.5 chunks of 64 meters is... um |
| 21:39 | < Janus> | 288 meters! |
| 21:40 | < Janus> | The extra range is more for ecosystem stuff I wanna put in... having it freeze when you wonder too far away would play havoc with that though |
| 21:41 | < Janus> | ... I don't know how far a meter is I just realized. *looks it up* |
| 21:42 | < Janus> | Oh, three football fields! |
| 21:42 | < Vornicus> | Heh |
| 21:43 | < Janus> | Maybe. Oh! I know! |
| 21:43 | < Vornicus> | try 7x7 instead - 40% less stuff, and still more render distance than minecraft. |
| 21:44 | < Janus> | The compression only hits performance when adding, checking, inflating and deflating, right? |
| 21:44 | < Vornicus> | RIght. |
| 21:45 | < Janus> | ... y-yeah! Only uncompress the closer chunks, and the farther away ones that are used for other stuff can be compressed, since those systems will only be checking a few blocks at a time |
| 21:46 | < Janus> | ... *turns red* |
| 21:48 | < Janus> | I miscalculated. (too many numbers fah!) 7x7 x 64x64x128 x 2(two layers of chunks) x 12(block size) = 588 MB |
| 21:49 | < Vornicus> | Oh good god. |
| 21:49 | < Vornicus> | OKay, so, no. |
| 21:49 | < Vornicus> | 1. See if you can reduce block size. |
| 21:50 | < Vornicus> | By doing that you can probably halve or even quarter memory footprint for this. |
| 21:51 | < Vornicus> | Chest and signs, since they're not common, you can have a lookup table attached to the chunk that has xyz and chest/sign data in it. |
| 21:53 | < Vornicus> | You don't need to spend a megabyte per chunk on that. This reduces your footprint by 98 MB, to 490. |
| 21:53 | < Vornicus> | A similar argument could be made for subvoxels. |
| 21:53 | < Janus> | ... oh! That's a good idea, aha! The fact that it'd be a chest-type block, would prompt it to look for the chest data from there. So that variable is totally unneeded |
| 21:55 | < Vornicus> | What are you using subvoxels for anyway? |
| 21:57 | < Janus> | They serve a few purposes. Plain blocks like dirt and stone can be weathered. When you break blocks, you take out chunks until it's eventually runs out of HP so to speak, and the whole block goes. You can use a chisel and carve into it without popping it too. Silicon blocks use it for circuits. Fluid blocks use it for pressure data. etc |
| 21:58 | < Vornicus> | Ew ew ew. |
| 21:58 | < Janus> | Was that at the popping, or the terrible reuse of data? xD |
| 21:59 | < Vornicus> | All of it. |
| 22:02 | < Janus> | Aha! Well it certainly hasn't made any of this any easier, but I gotta add something to minecraft, outside of just... well, more blocks. xD |
| 22:05 | < Vornicus> | Howe about 2x2 subvoxels? |
| 22:07 | < Vornicus> | That's only 1 byte, saving you 343 MB. |
| 22:08 | < Vornicus> | Even 3x3 subvoxels - about 2.5 bytes per chunk - saves you 269.5MB |
| 22:12 | < Vornicus> | And while we're in the neighborhood: Lighting? |
| 22:12 | < Janus> | With 3x3, the pixels in the 16x16 textures get clipped a bit, I gave it a try. 2x2 does make it a load simpler though, that's for sure. |
| 22:14 | < Vornicus> | Minecraft's per block structure is 1 byte "type", 1 byte lighting, and 0.5 bytes state. |
| 22:17 | < Janus> | For lighting I had 1 byte too, but it's used kind of obtusely. 8S |
| 22:17 | < Tarinaky> | Vornicus: What's 0.5 a byte? |
| 22:18 | < Vornicus> | 1 nybble |
| 22:18 | < Tarinaky> | Oh. Derp. |
| 22:18 | < Tarinaky> | Misread that as bit. |
| 22:18 | < Janus> | Stored in a seperate location from the blocks themselves, since the lighting covers all 64x64x128 spots. Basically, 1 nybble for x, 1 nybble for y |
| 22:19 | < Janus> | Those would've been used to track back to the light source and get lighting info from it. So I could add flicker, hue, etc |
| 22:19 | < Vornicus> | (Minecraft has two nybbles for lighting: one for sunlight, one for other light; the lighting formula is max(min(current_daylight_level, sunlight[x][y][z]), other_light[x][y][z]) |
| 22:19 | < Janus> | Ran into the problem of more than one light source influencing a single block though |
| 22:20 | < Janus> | I think it's been changed, since skylight now comes in blue/white variations, and sources of light come in gold |
| 22:21 | < Janus> | But I finally see how he got that affect now |
| 22:21 | < Vornicus> | Yeah, it has. |
| 22:22 | < Vornicus> | He added a texture that contains the lighting levels, and chooses the UV based on the lighting. |
| 22:23 | < Janus> | ... oh, you can put textures on textures? ... I ... I might want to do that instead |
| 22:23 | | * Janus was directly editing vertice colour |
| 22:23 | < Vornicus> | Multitexturing |
| 22:23 | < Vornicus> | That's how he used to do it. |
| 22:24 | < Vornicus> | (the vertex color that is) |
| 22:24 | < Janus> | It's the only way I can think of achieving gradients |
| 22:30 | < Vornicus> | (the other way is just coloring corners and turning on gauraud shading) |
| 22:33 | < Janus> | ... you know what you got a point. The more I objectively look at these subvoxels... aha. I mean. Lighting, I barely managed to get work, (they acted like translucent blocks based on the rows of missing voxels present). And now that I think about it, fluids wouldn't behave right around them, and it'll make the physics stuff 16 orders harder |
| 22:35 | < Janus> | It's a shame though. Without that, I'm gonna have to find something else that seperates it from minecraft. |
| 23:53 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| --- Log closed Sat Oct 01 00:00:39 2011 |