Post screenshots of stuff you're working on!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

Entheogen posted:

cheap trick, since i didn't want to do ray casting algorithms or volume finding ones. I just draw cubes that connect each data point with its neighbors, and then use GL_SMOOTH to interpolate between vertices on same triangle. What i do exactly, is draw a triangle fan for each point that covers 3 faces of a cube.

My understanding is that volume ray casting is considered to be the way to go these days. Still, even if you decided to do it the "easy" way, why not just use view oriented quads that slice through the volume rather than millions of triangles?

# ¿ Jun 30, 2008 12:48

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 22:02

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

Entheogen posted:

You mean i can sort of calculate the "voxels" i need to display to approximate "real" view then render it using quads?

I have seen some real time ray-casting demos and the performance didn't seem that much higher than what I have right now. Also ray-casting is usually for rendering solids and semi-transperent layers that cover them, as far as I understand. With this project its more that I need to look "inside" the volume at all levels and be able to isolate different features inside.

Take a look at voreen for an open source ray-casting based volume rendering engine. I haven't played around with it much, to be honest, and it does require Qt, but it just works.

By drawing a number of little cubes, you are effectively drawing 3 sets of volume oriented planes through your domain (ones perpendicular to the volume's X, Y and Z axes). However, you're essentially drawing 3 times as many planes as you need. If you, instead, figure out how big the volume in screen space is, you can draw a stack of quads that are perpendicular to the viewing direction and intersect your volume. Using hardware trilinear interpolation (assuming your volume is a 3D texture), you'll get a decent result using this approach.

# ¿ Jun 30, 2008 13:30

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

Zakalwe posted:

My advice? Stick with the rasterisation for this application at least.

Did you even read what he's been posting? He's doing volume rendering. GPU based ray-casting is a very common technique to achieve this in real time. I even posted a link to an open source application that does this. Thanks for your input.

# ¿ Jul 2, 2008 13:00

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

I've finally gotten my Large-eddy Simulation on the GPU mostly working thanks to CUDA. Here's a screenshot of some simulated cumulus clouds:

I still have to improve the rendering and try to improve the numerical stability a bit.

# ¿ Jul 18, 2008 11:53

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

Zakalwe posted:

How are you finding the CUDA SDK on Ubuntu? A friend of mine just got his Geforce 280 for CUDA and is looking at putting Ubuntu on his machine to use it (He generally uses FreeBSD). Any weird pitfalls you encountered?

I found it a bit difficult to get started. I'm using the CUDA 2 beta 2. It requires installing the beta graphics driver from the NVIDIA website so you can't use either the standard NVIDIA driver or use envy to install a driver. Also, to get STL to work, you have to use gcc 4.1. After that, it's just the usual CUDA pitfalls which are many.

# ¿ Jul 18, 2008 17:34

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

From Earth posted:

A smoke/fluid simulator I'm working on for a visualization course.

Using the rainbow color map in a visualization course is a bit :psyduck:

# ¿ Sep 14, 2008 12:34

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

From Earth posted:

I didn't come up with the rainbow color map (it was already in the framework provided by the course teacher), but what's so strange about it?

It artificially breaks up the image into different regions that may or may not correspond with actual regions in the data. There are also some issues with the perceived transitions between the colors not all being the same.

Look up the papers "Data visualization: the end of the rainbow" and "Rainbow Color Map (Still) Considered Harmful" for a more in depth explanation.

EDIT: The second article in particular has some great example images that show how the rainbow color map can be misleading.

StickGuy fucked around with this message at 14:48 on Sep 15, 2008

# ¿ Sep 14, 2008 19:33

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

Adhemar posted:

Ah, I was so sure that software was Alex Telea's. I guess it might still be. Huub van de Wetering was in my exam committee when I graduated last march.

Alex Telea is in Groningen now I think.

# ¿ Sep 17, 2008 09:04

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

My cloud simulation is now more better.

# ¿ Sep 24, 2008 17:05

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 22:02

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

Avenging Dentist posted:

Writing an EBNF grammar is simple and fault-safety falls out of the parser automatically. Portability issues (e.g. endianness) vanish. Parsing languages is a well-known problem and many tools exist to simplify it (e.g. Flex/Bison).

This is tricky though. It's easy to write a parser in Flex/Bison to accept a given grammar. It's harder to write one that gracefully handles input not accepted by the grammar.

# ¿ Jan 31, 2009 18:11

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!