|
EAT THE EGGS RICOLA posted:'sup d3.js + topojson buddy! I made a thing for the united way at a thing last weekend. This is really really neat. I'm keen to try that sort of thing out myself - anywhere I should start? Like, tutorials and stuff? I'm not sure really what I'm looking for when I tried finding stuff myself earlier.
|
# ? Apr 20, 2014 04:44 |
|
|
# ? Jun 10, 2024 12:54 |
|
Woodsy Owl posted:Yeah I had it on Desura about maybe a month ago? Is the version available for DL now the most updated version? The latest version of the game is live on Desura yes. It's version 0.8. If you can fly into the big sphere at the centre of the game world you are on the latest version.
|
# ? Apr 20, 2014 13:38 |
|
Mock and Droll posted:This is really really neat. I'm keen to try that sort of thing out myself - anywhere I should start? Like, tutorials and stuff? I'm not sure really what I'm looking for when I tried finding stuff myself earlier. The problem with d3.js is that the learning curve is vertical if you don't know javascript. For the thing I linked, I took an ESRI Shapefile (the only format that was provided), and turned it into a GeoJSON file, then made a TopoJSON file out of that, then associated the data with each neighbourhood with each object. After that, I did something like this to generate the map and set up zooming to each neighbourhood's bounding box. You can get a list of sample code to do lots of things with d3.js here Factor Mystic posted:Nice. Although it may be interesting to represent the % breakdown visually as well as hard numbers, just to make scanning easier. I have data for a couple hundred different things for each neighbourhood, they just asked me specifically to display this (which was for a two-day event and I had to spend the first day cleaning their data). I was going to eventually add choropleth maps and a bunch of other ease of use stuff.
|
# ? Apr 20, 2014 14:53 |
|
You're also pretty hosed if you can't visualize how your data is stored and parsed. The worst part is the JavaScript debugging experience. Not a lot of help to get there. d3.js is utterly amaing, when it works, though. EDIT: That Animaniacs piece is awesome and something I've wanted to do. How did you go about lining up the timing of the lyrics with the countries? ufarn fucked around with this message at 22:35 on Apr 20, 2014 |
# ? Apr 20, 2014 22:30 |
|
ufarn posted:EDIT: That Animaniacs piece is awesome and something I've wanted to do. How did you go about lining up the timing of the lyrics with the countries? He just set up a trigger for each country
|
# ? Apr 20, 2014 23:46 |
|
EAT THE EGGS RICOLA posted:The problem with d3.js is that the learning curve is vertical if you don't know javascript. Oh Jesus. I know a bit of Javascript, I'll have to see if I can make sense of everything. D3 looks pretty neat with the stuff you can do. Thanks! If I manage to get something up and working, I'll post back.
|
# ? Apr 21, 2014 02:10 |
|
ufarn posted:EDIT: That Animaniacs piece is awesome and something I've wanted to do. How did you go about lining up the timing of the lyrics with the countries? Yep, I hand entered the timings. That was probably the bulk of the labor, actually. That and figuring out a way to avoid timer drift so that the timings stayed in sync with the song. I ended up using a d3 timer to continuously check the audio tag's current time. Theoretically I could set up timings for state capitols, put in a new topojson file with a fixed projection, and then have Wakko's 50 States song. But I'm not really wanting to repeat the timing labor again any time soon.
|
# ? Apr 21, 2014 02:59 |
|
I donated 0.000001 mBTC of my Bitcoins to your cause. Enjoy the 1/754th of a cup of coffee!
|
# ? Apr 21, 2014 03:03 |
|
Factor Mystic posted:Yep, I hand entered the timings. That was probably the bulk of the labor, actually. That and figuring out a way to avoid timer drift so that the timings stayed in sync with the song. I ended up using a d3 timer to continuously check the audio tag's current time. Theoretically I could set up timings for state capitols, put in a new topojson file with a fixed projection, and then have Wakko's 50 States song. But I'm not really wanting to repeat the timing labor again any time soon. Oh Jesus, by far the hardest part of map-related stuff with d3.js is setting up the projection properly.
|
# ? Apr 21, 2014 03:18 |
|
EAT THE EGGS RICOLA posted:Oh Jesus, by far the hardest part of map-related stuff with d3.js is setting up the projection properly. For a globe, the built in orthographic projection is sufficient (although I did use a modified rotation calculation, developed by Jason Davies, because it looks a bit better in motion). For the USA, I assume the built in Albers USA projection would work.
|
# ? Apr 21, 2014 04:37 |
|
Factor Mystic posted:For a globe, the built in orthographic projection is sufficient (although I did use a modified rotation calculation, developed by Jason Davies, because it looks a bit better in motion). For the USA, I assume the built in Albers USA projection would work. Yes on both of those points, but if you're trying to map anything that is not either the US or the world it's a giant pain
|
# ? Apr 21, 2014 14:36 |
|
I made a video of my voxel renderer: https://www.youtube.com/watch?v=fH66HBJ4UsY
|
# ? Apr 23, 2014 01:04 |
|
MarsMattel posted:I made a video of my voxel renderer: https://www.youtube.com/watch?v=fH66HBJ4UsY It still looks fantastic right now, though, don't get me wrong.
|
# ? Apr 23, 2014 04:13 |
|
Thanks I've looked at the various heightmap LOD schemes and yes, this version is pretty close to Chunked LOD. The hard part with the dual contouring was generating the seams between the chunks. Now I've got that working pretty well, I can start looking at the popping. I looked into geoclipmapping and CDLOD -- they seem to work on skipping indices (as I understand it), so the different LODs are still drawing the same vertices, just with different sets of indices. My voxel implementation handles the LOD by simplifying child nodes to generate the parent nodes, so the mesh for LOD0 doesn't contain any of the vertices for LOD1, etc (i.e. each time a chunk's LOD changes, a new mesh is generated). I think that rules out a (straightforward) adapation of geoclipmapping. My current best idea for avoiding the popping is some sort of progressive mesh, though I've not really looked into that at all.
|
# ? Apr 23, 2014 11:14 |
|
MarsMattel posted:I've looked at the various heightmap LOD schemes and yes, this version is pretty close to Chunked LOD. The hard part with the dual contouring was generating the seams between the chunks. Now I've got that working pretty well, I can start looking at the popping. You COULD also try to apply a stitching algorithm to stitch the layers, since they don't teeecchhniically need identical verts, but... man, that would get bonkers fast. The alpha blended approach might be good-enough though.
|
# ? Apr 23, 2014 14:33 |
|
I see, thanks for the explanation. This is my first proper graphics engine thing so I may be fairly clueless about some things I think one additional problem I have versus traditional heightmaps is that each of my chunks is entirely disconnected from its neighbours and a 'seam' mesh per chunk is require to fill in the gaps. I'm not sure how that would play out, lots of experimentation required I think.
|
# ? Apr 23, 2014 14:58 |
|
I made a thing! Its a two player draughts game, 8x8 board, no AI. Mostly to test out node-webkits packaging, but also to actually complete a personal project before losing interest for once. If anyone wants to have a play, here's some links: mac osx windows And for linux you can dl the terrible source (also for not linux, but I only tested the init and build scripts on linux).
|
# ? Apr 23, 2014 20:16 |
|
I'm still chipping away at some hardware reverse engineering with the BeagleBone Black. First, some SPI (clock signal on yellow channel, data on blue), but via userspace accesses of the mmap()'d SPI control registers: This avoids the overhead of an ioctl() call to flip from userspace to kernel space for the (notoriously slow) spidev driver to do essentially the same thing. This is for a different development project that I'm working on, but I hope to leverage some of this to drive SNES controllers. I'll get the controllers working directly via bitbanged GPIO once I am able to put some time into developing the PRU assembly code to drive the GPIO pins. The small board on the breadboard next to the BBB is a 4-bit bi-directional level converter board put out by AdaFruit. It uses four BSS138 FETs. That should allow me to go from the 3.3v of the GPIOs to the 5v microcontroller inside of the SNES controller. Also, Parallax recently had NES controller sockets on sale for 50 cents each, so I did the only rational thing that I could do: There might be a 4-socket NES BBB controller cape in my future, since the protocol is pretty similar to that of the SNES controllers.
|
# ? Apr 24, 2014 04:38 |
|
hendersa, never stop posting. I don't understand more than 1% of what you're doing with your bit banging and byte wrangling, but I love reading it anyway.
|
# ? Apr 24, 2014 05:01 |
|
Seriously. Your posts are an education.
|
# ? Apr 24, 2014 13:53 |
|
Kumquat posted:hendersa, never stop posting. I don't understand more than 1% of what you're doing with your bit banging and byte wrangling, but I love reading it anyway. Thanks! If there is something in particular that you see that you don't understand and want to know more about, let me know. pokeyman posted:Seriously. Your posts are an education. I wish I had more time to work on this stuff, but I always have so much going on. Aside from working on a PhD, I also answer dozens of mails every day about my software work. That eats up a ton of time. Just today, I've received mails from grad students in Thailand, South Africa, and Syria asking for technical details to help with embedded system thesis projects. I had one person send me a mail letting me know that my port of Android to the BeagleBone Black was featured in an Android performance comparison video: https://www.youtube.com/watch?v=X_up9doF72I The benchmarks at the end are for the older TI-ish Android image (using the older 3.2 kernel) while the rest of the video uses my image with the 3.8 kernel. Hopefully, the video will encourage people to talk to the Udoo guys about Android and give me a little bit of a break! I had a publisher contact me a few weeks ago about writing a BeagleBone Black book, but I had to turn it down because I can't spare the time. hendersa fucked around with this message at 16:38 on Apr 24, 2014 |
# ? Apr 24, 2014 16:26 |
|
I've been doing things to the Eclipse IDE, hacky, weird things:
|
# ? Apr 24, 2014 22:38 |
|
Max Facetime posted:I've been doing things to the Eclipse IDE, hacky, weird things: The only thing I don't necessarily like about that is that it names the variables "go" and "here" when there's functions with that name already. Maybe check if there's a function that shares the name, or perhaps give it a slightly different name like v_go or something to differentiate it. Otherwise, really neat! I like that it goes backwards too.
|
# ? Apr 25, 2014 01:01 |
|
Jewel posted:The only thing I don't necessarily like about that is that it names the variables "go" and "here" when there's functions with that name already. Maybe check if there's a function that shares the name, or perhaps give it a slightly different name like v_go or something to differentiate it. Thanks! Those little popup lists that show up allow renaming the new variables but in the demo I'm just smashing Enter to speed through all that. Edit: Actually, there's a setting to do exactly that: Max Facetime fucked around with this message at 07:39 on Apr 25, 2014 |
# ? Apr 25, 2014 07:11 |
|
Max Facetime posted:I've been doing things to the Eclipse IDE, hacky, weird things: This looks real useful. How difficult was it to extend Eclipse? PS: minus.com image hosting is loving garbage that doesn't load 90% of the time. I had to use chrome to get the image to load and it only did after 30 minutes.
|
# ? Apr 25, 2014 20:25 |
|
hendersa posted:I'm still chipping away at some hardware reverse engineering with the BeagleBone Black. First, some SPI (clock signal on yellow channel, data on blue), but via userspace accesses of the mmap()'d SPI control registers: Ahh, ringing and overshoot. Perfectly OK in this application but still makes me a bit ehhhh. Excited to see the PRU stuff. Recently finished writing a custom bootloader and a bunch of U-Boot modifications to support our SoC work as well; only two instances of spending hours poking at one register
|
# ? Apr 25, 2014 22:09 |
|
Shinku ABOOKEN posted:This looks real useful. It feels more difficult than it is. If asked six months ago, I would have said hardest part would have been getting it all to compile, to run and then to build into a custom version that you can use like normal. After all the Java 8 dust has settled a bit though, I'd say the hardest part is finding out about features that you didn't know existed that could be customized in new ways and then drilling down into the right code to make small surgical changes. The codebase is huge and quite old in some parts, but not really difficult to read. There is just so much of it to read that you need good search tools if you want to find a certain thing again later. I have all the code linked in a folder under one "all links go here"-project so even if I don't have the correct plugin checked out I can at least find out which plugin houses the thing I'm trying to find. I also have a plugin called Quick Search which let's you select some text and then find all other occurrences of it with a single key press. For this feature, I saw a bug report suggesting that it should be possible to extract new local variables without needing to select the text of the whole expression first. OK, that's a good idea. There was also a question about why the reporter preferred to use this one Extract Local Variable command and not this other Extract Local Variable command. Wait, there's two such commands? Yep, one pops up an input field for you to enter a name for the new variable and the other one does what you see in the GIF. Except the other one is just as picky about the user having exactly the right text selected as the first one. Worse, when the selection isn't just right the second one doesn't really bother with error messages, it just doesn't do anything. So, find the command in key bindings, see it's called "Quick Assist - Extract local variable". Search for the "Quick Assist - Extract local variable" text, see it's internationalized with the key "ActionDefinition.corrections.extractLocal.name". Search that, find that its command ID is "org.eclipse.jdt.ui.correction.extractLocal.assist". Search that, find that it's used in a EXTRACT_LOCAL_ID constant in class QuickAssistProcessor. That sounds like the right place, and indeed, there is the getExtractVariableProposal -method which takes an AST node and chooses what can be done with it. I'm skipping over quite a few details but that's the general flow. Shinku ABOOKEN posted:PS: minus.com image hosting is loving garbage that doesn't load 90% of the time. I had to use chrome to get the image to load and it only did after 30 minutes. Goddamn it. And I was quite happy with Minus too. I guess I'll use attachments until I find a better host that doesn't mess with my pixels.
|
# ? Apr 26, 2014 00:07 |
|
quote:Goddamn it. And I was quite happy with Minus too. I guess I'll use attachments until I find a better host that doesn't mess with my pixels.
|
# ? Apr 26, 2014 00:17 |
|
Also hendersa, see if you can't get someone to get you one of the new Saleae Logic's, it'd be super useful for what you're doing.
|
# ? Apr 26, 2014 00:50 |
|
So I'm writing a viewer for KCL files, which are Mario Kart Wii's collision data for the tracks. Looking good so far! C++ and OpenGL. Going to be coloring the walls based on what "tag" they have (floor, wall, lava, water, void, invisible wall, boost, etc) later.
|
# ? Apr 26, 2014 00:54 |
|
Jewel posted:So I'm writing a viewer for KCL files, which are Mario Kart Wii's collision data for the tracks. Well that's cool as gently caress. Are you reverse engineering the format or is there some prior work on that?
|
# ? Apr 26, 2014 01:28 |
|
pokeyman posted:Well that's cool as gently caress. Are you reverse engineering the format or is there some prior work on that? Luckily there's some prior work. There's a wiki devoted entirely to mario kart file formats and editors. The page on KCL data can be found at: http://wiki.tockdom.com/wiki/KCL_(File_Format) It's a relatively simple format, although they store 24000 vertices and only 4000 of them are unique (each point is shared by roughly six tris, so the number makes sense assuming they did no optimisation for some reason), which is a little dumb (especially since the triangles use an index into the vertex array, which means there's absolutely no reason to do this. I'm probably gonna try and optimise the file format later and re-export with the exact same information but with a much smaller file size, as an exercise. Also the triangles are stored as:
And it calculates the 2nd and 3rd vertices of the triangle with this math: code:
Storing 3 normals and a float, to calculate two vertices, is really really weird. That's 10 floats to calculate 6 floats. Plus extra load time. The other normals aren't vertex normals either they're pointing in very strange directions, what seems to be purely to calculate the other vertices.
|
# ? Apr 26, 2014 01:44 |
|
movax posted:Ahh, ringing and overshoot. Perfectly OK in this application but still makes me a bit ehhhh. Excited to see the PRU stuff. Sadly, the SPI on the BBB is really bad in terms of signal. That isn't a bitbanged GPIO, but the actual output of the hardware SPI. I'm just turning on the channel and loading data into the TX register. The clock and data signals that you see are the same as what you would see coming from the kernel driver. When there is data to TX, the clock is active. movax posted:Also hendersa, see if you can't get someone to get you one of the new Saleae Logic's, it'd be super useful for what you're doing. A logic analyzer is next on my equipment list. I figured that I'd start with the scope to see what I'm dealing with, and then take it from there. I buy equipment as I can with the Paypal donations that come in, which all goes straight into the "new equipment" fund. The scope has been very nice so far, since I only had a multimeter to see what was going on before. I'm also still learning to use the scope to its full potential. I spent two hours swearing at it the other night while figuring out the trigger/stop mechanism. Good times! hendersa fucked around with this message at 01:57 on Apr 26, 2014 |
# ? Apr 26, 2014 01:52 |
|
hendersa posted:Sadly, the SPI on the BBB is really bad in terms of signal. That isn't a bitbanged GPIO, but the actual output of the hardware SPI. I'm just turning on the channel and loading data into the TX register. The clock and data signals that you see are the same as what you would see coming from the kernel driver. When there is data to TX, the clock is active. I am familiar with that scope as I own it. It is one of the few good scopes you can find in consumer land on amazon! I recommend it highly.
|
# ? Apr 26, 2014 10:15 |
|
pokeyman posted:Well that's cool as gently caress. Are you reverse engineering the format or is there some prior work on that? There is a whole mod for Mario Kart Wii which adds a shitload of tracks from previous titles. The only reason I bring it up is so that everyone reading this might be on the same page if they weren't already.
|
# ? Apr 26, 2014 13:36 |
|
Jewel posted:Luckily there's some prior work. There's a wiki devoted entirely to mario kart file formats and editors. NormalA, Direction and NormalB, Direction are planes Whoever wrote that knew something we didn't. That sounds like an optimization for the collision engine to me.
|
# ? Apr 26, 2014 14:23 |
|
Dred_furst posted:NormalA, Direction and NormalB, Direction are planes Yeah, Suspicious Dish figured that out today. I'm gonna look further into displaying the normals to see what exactly the planes could be used for regarding physics.
|
# ? Apr 26, 2014 14:25 |
|
Jewel posted:Yeah, Suspicious Dish figured that out today. I'm gonna look further into displaying the normals to see what exactly the planes could be used for regarding physics. It looks like storing the two other planes is an optimization for triangle/triangle collision tests. the code to calculate the two other planes is a lot more than the code you've written for calculating the two other vertices. (Judging from SharpDX's method) Unfortunately, I don't have my book on collision detection with me, otherwise I'd find the exact piece of maths required. It's likely to be a variant of Moller's triangle-triangle algorithm.
|
# ? Apr 26, 2014 14:40 |
|
Jewel posted:Yeah, Suspicious Dish figured that out today. I'm gonna look further into displaying the normals to see what exactly the planes could be used for regarding physics. When you posted the algorithm to me before, I was commuting to work. When you posted this here, I really studied it depth and started visualizing the geometry and it just clicked. I knew there's plenty of clever collision detection algorithms that rely on dumb snake oil trickery based on planes pointing in weird directions. I don't pretend to understand any of them, but any links anybody has, like the one to Moller's, are great. Why they have 4000 unique verts and only 2500 or w/e used is just Nintendo's stupidity. Unless it's some dumb clever "optimize for disc seek time" trickery. Which it's not, because MKWii was rushed and that's like the last item you will ever do in development.
|
# ? Apr 26, 2014 15:21 |
|
|
# ? Jun 10, 2024 12:54 |
|
Suspicious Dish posted:When you posted the algorithm to me before, I was commuting to work. When you posted this here, I really studied it depth and started visualizing the geometry and it just clicked. I knew there's plenty of clever collision detection algorithms that rely on dumb snake oil trickery based on planes pointing in weird directions. I don't pretend to understand any of them, but any links anybody has, like the one to Moller's, are great. This book (Amazon) is an absolute godsend for collision detection routines. Yes it's pricey but it has basically every type of intersection query you could want. It also has very good chapters on geometric robustness and dealing with floating point accuracy problems within geometric problems. It also has a lengthy section on object hierarchies and optimizing collision routines.
|
# ? Apr 26, 2014 17:09 |