Voxels, it seems like everybodys doing them nowadays, well at least here on your board Ken. :D
So, about 2 or 3 weekends ago or some approximation thereof I decided to see if I could make something of a voxel renderer. So I took my 3D Matrix Math system and a 3D point and draw a square that could be scaled from it and moved it around in space. That was my first Voxel, it seemed easy enough.
So next I make a huge array, three of them to be precise and procedurally generated a 3D Cube. It was slow...because I had no Voxel Culling and it looked wonky because I didn't Z-Sort anything. Still it was a Voxel Cube so I was pleased.
Next, I optimized things a bit and cleaned them up (only for them to be hacked up again :D) and started thinking about how to make my Voxels more interesting. I looked at your Voxel Modeller and it was good, but too complex for what I wanted to do. So I looked at a QBasic Voxel Modeller and it seemed nice, but I didn't want to rip anything off of it. So I contemplated for a moment, and I remembered something. Jonathan Wallace of Wallace Software, he had a Heightmapped DooM Plasmagun on his site long ago that struck me as interesting. So I set off to re-create that vision but with my own stylish and Voxelized flair.
I thought well, what if I took a Bitmap and converted it into voxels. That was a good start, so I got a brick wall texture and made a Voxel Brick Wall, and it was good. I was on a roll I thought, as I furrowed my brow and kept coding. Next I added a little cursor/grid to adjust the height/depth of your voxels. Now I could make 1/2 of a hollowed out Voxel model. This worked nicely, so I then added the option to Mirror the model and make it 'whole', making it a complete 3D Object. This worked fine, after I added Z-Sorting. :D
Anyway, and that's about what we have here now, a little Voxel Experiment that surprisingly went right. :) Hope you like it guys.
Edited by Jinroh at
0xC0DE at
Re: Sprite2Voxel my take on Voxels
Curse you! I need to do some other import stuff today, but this looks so awesome I want to code my own little voxel bitmap thingie.
only weird thing I noticed was when you zoom in on the object too much, the voxels get a lot of space between them, and that doens't look right.
other then that; AWESOME!
0xC0DE at
argh, really can't stop thinking about this. I've tried some other sprites, and if they get bigger they run slower (doh). but I think you could really speed things up. Here are some ideas I'm thinking of right as we speak :
my guess why it's runs slow is that you transform every voxel/vertex point of the bitmap every time. This isn't really necessary. In fact you can get away with transforming only 4 points (no matter how big the bitmap is!).
Well since a sprite or bitmap is flat. We know that all voxels will have the same depth, right ? let’s take this sprite as example :
http://www.tremorsoftware.eu/meuk/imp001.PNG
Now, what we need to do is find the bounding box of the sprite like this :
http://www.tremorsoftware.eu/meuk/imp002.PNG
The 4 corners become our only real vertex points! :
http://www.tremorsoftware.eu/meuk/imp003.PNG
I’ve put Z in black because it doesn’t depend on the bitmap , but what the user or programmer wants it to be.
Now all we need to do is calculate the step size between the vertex points if they rotate, just like you would do with a polygon. :
http://www.tremorsoftware.eu/meuk/imp004.PNG
constAB would be :
constAB = (A.x – B.x) / (A.y – B.y);
Maren at
How about giving bitmaps some depth by placing more voxels on the brighter colours and less on the darker?, not that it would look amazing, but it's a start...
0xC0DE at
how about inputting 2 bitmaps ? one side view, and one front view. This doesn't work for items, but it should work for enemies (games such as wolfenstein,doom all have enemies with multiple angles).
Jinroh at
Wow, I didn't know my little app would create such a stir. Thanks guys. You saying its awesome 0xC0DE, that means a lot.
Yeah, there is no Voxel Culling in there so I do draw everything every frame (I couldn't figure out a way to cull those stupid voxels), and I used a Bubble Sort for the Z-Sorting just to get it in there really quickly, I'll definitely change it though. I'm still working on my Software Rendered Engine atm so I can't tell you when.
Right now the way the rotation, translation, scaling runs is that I use a master world matrix that I setup and then multiply the voxels by the matrix and project them. I thought that would be the most efficient way of doing that instead of setting one up for each Voxel, but I could be mistaken. I could always use linear interpolation like you suggested 0xC0DE, but I think they would be about the same speed. Unless I misinterpereted you explanation of course, ;)
As for the Voxels splitting apart when the are scaled too largely, yeah, that's probably because the size of the voxels depends on the Z Axis and since they're being scaled and not moved they stay the same size. I think that's the reason, I'd have to look at it again.
Changing the Voxel's Depth based on the brightness of the pixel isn't a bad idea Maren. For some sprites it would be good, like the ones by the boys over at iD.
As for Multiple Views of the characters, I thought about it, and my best implementation would be to make a 64x64x64 Cube of Voxels that you could load the bitmaps into. Then edit them that way, for the X/Y/Z axes.
EDIT: I was going to ask you guys if you wanted me to release the source, I decided against that with the advent of some new ideas I just thought of that actually have some use to me. :P Since all of you are equal or better coders than I you would probably enjoy starting with a clean source window anyway. However, I'll describe my process for any curious onlookers that may find this on Google or something.
Step 1: Load a Bitmap Step 2: Create an array of Voxel data with the size of BmpWidth * BmpHeight Step 3: Loop Through the X and Y Coordinates of the Bitmap from -BmpHeight / 2 * BaseVoxelSize to BmpHeight / 2 * BaseVoxelSize for the Y and -BmpWidth / 2 * BaseVoxelSize to BmpWidth / 2 * BaseVoxelSize for the X to ensure that center of your model is 0, 0, 0 if you like that orientation. Step 4: While looping through record the local coordinates as X = xLoop, Y = yLoop, Z = 0, and the Colour Value is whatever the Pixel of the BMP is at the current X/Y values.
Now you have an array of Voxels that are all ready to be rendered.
Do Your Transformations and Projections, loop through the list and render the Voxels. If any of the Voxels have a Colour Value of 255, 0, 255 (Magenta) or whatever your favorite transparent colour value is, skip it. Don't forget to Z-Sort.
Edit the Z Values of your voxels to adjust the depth of your object. That's about the general gist of what I did, nothing really mind blowing just a lot of simple 3D stuff all rolled into a voxelizer.
I can't wait to see what you come up with 0xC0DE, you've got crazy talent so I'm interested to see how your's blows mine out of the water. :D Anyway, thank for the support guys.
Edited by Jinroh at
0xC0DE at
just got back from the beach, and I'm pretty tired. But I know myself just too well; I won't stop thinking about this until I wrote at least a little prototype. :)
So I just made this in 1 hour, and it's still pretty much as brute force as you can get. Anyway, here’s the GBA rom and a screenshot (gotta love the big voxels).
http://www.tremorsoftware.eu/meuk/spr2vox.gba
http://www.tremorsoftware.eu/meuk/spr2vox.gif
Edited by 0xC0DE at
Jinroh at
Dude, that's awesome. I had no idea that was an Imp from the screenshot though, but once I loaded up the ROM on my SuperCard I was like, "Dude, that's an Imp." Works pretty well for being rendered on the GBA. Mode 4? But dang man, you love your GBA and Cell Phones, and DS. lol.
Anyway, that's freakin' sweet. That's about how far I was in an hour though so awesome job, and on the GBA no less. That makes it better than my 1 hour of PC work. :D
0xC0DE at
okay, worked on it for another hour, trying to optimize it with the ideas from my post above. Although it isn’t as clean as I wanted it to be, it’s pretty decent. The speed is currently better then your PC version, so that’s nice.
The imp looks also a little better (you can finally see it’s an imp from the screenshot!). And I’ve put in animations.
http://www.tremorsoftware.eu/meuk/vox.gif
How I optimized it :
As far as I can see the pc version and my first gba version both use the same approach. We transform each pixel/voxel every time we rotate. So if we have a 64x64 bitmap that would mean we need to transform 64x64 = 4096 points (if we don’t skip transparent pixels). That’s probably as brute force as you can get.
So, what did I do ? I transformed only the sides (left and right) between 0 and 64 on the y axe (while x = -32 and 32 respectfully). I then calculated the length between those points (So I can calculate the step size for the x and y axe) and plotted my voxels using these steps sizes (all in screenspace).
This means that instead of transforming 4096 points, I only need to transform 128 points (64 for each side). This can obviously gets even more efficient If I use the same trick on the y-axe (then only 4 points are needed).
What could be done better :
There are some glitches but I can’t really do anything about that, because I’m not using floatpoint math.
Speed, I think I could make it at least 2x faster.
Render pipeline, the transforming part and the drawing part are in a very weird render pipeline because of the side scanning. That could be done better.
The rom :
http://www.tremorsoftware.eu/meuk/spr2vox_v2.gba
Edited by 0xC0DE at
Apprentice at
Jinroh, I think that you use some sort of orthogonal projection on your voxels (they appear at the same size even if the zoom factor is changed) where a (x,y,z) point will relly on the projected plane on (x,y,0) coordonate. I hope I understood well, if no then sorry. You should use a perspective projection: something like this (the most common used) sx=x/z; sy=y/z; or sx=HalfScreenWidth+ScreenWidth*x/z; sy=HalfScreenHeight-ScreenHeight*y/z if you want your voxels to start from the center of the screen and change their size correctly if you change the resolution; As to the idea of converting 2D sprites to voxel objects you should follow Ken's idea on SLABSPRI (something like this I think): - you start from a cube of solid voxels of size, let's say, half of the bitmap maximal size - you run a group of carefully drawn bitmaps (which represent a set of the final voxel object rotations->a bigger number gets to a a better (precise) voxel object) and chop out any voxels that are behind a transparent color (in the bitmap) ->your magenta 255 color - you make another run through the rotations and paint the voxels with the color of the current pixel (representing the current voxel) on the current bitmap (if, because of the number of rotations being larger (I think) that the number of the cube faces or another because of another thing a voxel is being painted twice he is going to get the average color between the old color and the new one->for that you may want to get up and running a translucency table (where you mix p% of color1 with q% of color2, where p+q=100, and you put in the current table index the final color; transl[25][250] is the mixed color of color 25 and color 250 with the p,q procents constant on the entire table); - you then run through all the voxels and if you find one that hasn't been touched by the painter you then paint it with a random color from his neighbours.
If you'd do a "4DOF editor" you would be able to make a very fast renderer because you would be able to share calculations on every voxel column (if you would decide to render vertically because you would not have pitch and roll rotation available) and without the need of a Z Buffer you would easily render the voxel's columns in back-to-front order maintaning a grid->you would make a rotation on every column with the same matrix and because of the fact that all the columns are z constant you would make a single projection on every column and "find out" the other voxels screen coordonates on the same column by a few additions. But if you enable all three rotations then I think the first secure approach is using a Z buffer (if you aren't using one already). You can still make a 1/z (floating point) realtime table so that you don't project the same z voxel twice because a product is ussualy faster than a divide allthough is not a very good idea. I think you could still use a back-to-front rendering if you are maintaining a good 3D grid, I don't really know; I never implemented it. You can make use of backface-culling if your voxel object is full on the inside (if it is already hollowised then you won't produce a large amount of overdraw if you just render the voxels in back-to-front order) but (as Ken told me) me sure you make use of all 6 normals and not of an average one because this produces gaps. If you already knew the things I posted here, sorry and thanks to KEN that he likes to share his knowledge because a large amount of what I posted here is "inspired" from his replies.
Edited by Apprentice at
0xC0DE at
@ Apprentice You should take a better look at it, the voxels cleary have different sizes. Also Jinroh pointed out why he thinks the spaces get created.
-------------
I’ve tried to implement the same trick on the y-axe but It didn’t work out. Turns out the glitches get way too obvious (because I don’t use float point math). Also the speed increment was minimal against the latest version posted here, so I dropped it. It’s pretty damn fast anyway.
So, Jinroh, any news on those bright ideas you were having ? looking forward to them 8)
Edited by 0xC0DE at
Jinroh at
Apprentice:
Yeah, I use Perspective Projection in my renderer, maybe you have your resolution set too high or something. Making a 4DOF renderer would make it better speed-wise but we'd lose the the freedom of movement. Pending we'd make a fully 3D Game out of it. I get what you're saying though.
0xC0DE It seems like you did your animations similarly to how I was planning on doing them, you just beat me to the punch. Excellent optimization too, I get what you are saying about the left to right interpolation idea. That was a good call. You passing me up though, you're going to make me get back on this project aren't you? lol.
I had an idea of making the voxels a quad and then adjusting 1/2 of the quad's vertices when you adjusted the voxel depth to make things a bit more smooth and better for hardware acceleration for later, but it seems like more trouble than it's worth.
I did think about making the voxels height depend on colour darkness though. Something like (colour.r + colour.g + colour.b) / 64 or something like that. I didn't get to try it yet though. I got flat shaded objects into my polygon renderer today, so maybe I'll do some Voxel work tomorrow.
Anyway, awesome work dude.
Edited by Jinroh at
Ghostpilot at
Jinroh said at
Changing the Voxel's Depth based on the brightness of the pixel isn't a bad idea Maren. For some sprites it would be good, like the ones by the boys over at iD.
As for Multiple Views of the characters, I thought about it, and my best implementation would be to make a 64x64x64 Cube of Voxels that you could load the bitmaps into. Then edit them that way, for the X/Y/Z axes.
I found this thread today. Wow was I surprised to see that some people actually take action instead of just talking about voxels. Usually when you search for any information about voxels, the information you find is either too advanced or not in the scope of intrest. This was just what i have been looking for since the "never really alive" doom voxelization project started. (that is kind of lacking the both the renderer implemented in doom, the right tools and the right fileformat of the output work.
However, thinking of the "one sprite per view" there is a small problem. Especially in DOOM. At least when thinking about the enemysprites. They are drawn by hand and aren't the same height in the different rotation angles.
If going at it with this approach you need to scale some of the angles to be in sync with whatever angle you chose as base view.
A while back I started to "correct" the A-set of angles of the zombieman for later use in slabspri. It got kind of bothersome after a while or so of pixeling the images back together to a fixed size.
The idea about colour to shape method looks promising. Most of the sprites in DOOM are kind of dark.
Have you seen these pages? DOOM Voxel Project.
Everygraph's Voxel3D
Keep up the good work man! Oh, if you do descide to release the source, I would like to see it for educational purposes. I have some math skills, but not "3D-thinking".
Awesoken at
Is there a download for the Doom voxel project models? If I could get my hands on some good test models, that might be enough to motivate me to add support to Slab6 : )
Ghostpilot at
Awesoken said at
Is there a download for the Doom voxel project models? If I could get my hands on some good test models, that might be enough to motivate me to add support to Slab6 : )
I don't know if they currently are for download on the page. However, I can send you the ones I made. BUT... They are in the format voxel3d outputs.
Kind of lowres also since they are made with the original DOOM sprites as base. I can shoot some models your way. /T
Jinroh at
Hey Ghostpilot, thanks for the support.
Yeah, I did some Voxel searching a little while ago and didn't come up with much either, just the Voxel master Ken :) So I just took it one step at a time and used what hearsay I had heard to make something in the neighborhood of what looks right. :D
Hmm...I always thought that the DooM sprites were proportionally correct, but yeah they would need some changes made to them. I was playing around with the "Depth Colouring" approach to give values depth based on colour. The lighter values stick out closer to you and the darker ones hang back further. I used the (colour.r + colour.g + colour.b) / 64 equation and it worked rather nicely. Given that equation the colour values can have a range from 0 - 11 That definitely made things stick out and be all multi-depthed without having to change the values by hand. The DooM Plasmagun however, wasn't such a good test, the top of the Plasmagun is lighter than the bottom so it did not come out very symmetrical. So that lead me to think that perhaps the "Depth Colouring" should perhaps be done to half of the model and then those values should be applied to the other half to keep it symmetrical. I'm not sure though I'd have to run some more tests. I'm downloading some character sprites right now so I'm going to test them a bit more.
I'd post some screenshots of the tests I've run so far, but 1. They aren't really interesting 2. They're on my development laptop so it would take me a whole two minutes to get them off and uploaded ;)
I'll post something later today though.
Thanks for the links Ghostpilot I'll check them out later. I never even heard of either of them. They sound interesting though.
I'm probably going to release a basic version of my voxel renderer by the end of summer hopefully, http://cg.cs.tu-berlin.de/~ki/info/otmvoxel.html OTM Voxel Tutorial is one of the better ones that I have seen. They actually use a method similar to the one we are using, with Billboarded squares.
I have some math skills, but not "3D-thinking".
The kind of 3D we're doing here is really simple stuff, you'd be able to keep up just fine. Polygonal 3D is not all that much harder either. If you use OpenGL or DirectX it's simple as cake. That's why I started making my own 3D Software Renderer because I knew I would learn a lot more.
Anyway, thanks for the interest Ghostpilot.
EDIT: LATER TODAY
Hey guys I took a few minutes and tried a new version of my renderer with "Depth Colouring" and I tried it on the Commando from DooM sprite. It seems to work quite well. Decent enough to give it good depth anyway. I tried it with a few others and it seems to do its job the Bandolier on the Commando sticks out further from the body since it's a lighter colour but I think it still looks quite well, it makes the bandolier more striking. Like, "Yeah, I got bullets on me. What are you gonna do about it?" lol. Tell me what you guys think.
I really have to optimize my renderer though, though, with Depth Sorting disabled it's not so bad.
A link to DL the Depth Coloured one is here at www.geocities.com/solarofficial/commando.zip
I tried searching for those DooM Voxel models, but I couldn't really find anything.
Hope you guys like it.
Edited by Jinroh at
Ghostpilot at
Jinroh said at
Hey Ghostpilot, thanks for the support.
EDIT: LATER TODAY
Hey guys I took a few minutes and tried a new version of my renderer with "Depth Colouring"...
Jaw drops... What I tried to do by hand, your program did in less than 2 seconds.
It needs some tweaking though, but I can see what it is. And it's way beyond my expectations when I read that you just slapped this together.
Would it be possible to make some kind of hybrid between using one bitmap for more angles than front AND use depth colour fill. If there is big difference between what the angle bitmaps produce compared to what angle x color depth produce you could take the average and see if it's a more smooth result.
Jinroh at
I appreciate the posative feedback Ghostpilot.
Yeah, the method does need some tweaking before it is really acceptable, but it's a good start anyway. The way it works is by taking the (colour.r + colour.g + colour.b) / 64 value and applying it to the depth of each Voxel for one's that aren't magenta coloured. The equation yields a value between 11 and 0 which is a pretty good range for a human-oid sprite.
One of the ideas I have for an editor like you are talking about is to take a couple of grids like this: ------------------------ | | | | | | | | | | ------------------------ | | | | | | | | | | ------------------------ Sprite Height | | | | | | | | | | ------------------------ | | | | | | | | | | ------------------------ Sprite Width
Then load into them Left/Right/Front/Back views of the Sprite and then create a 3D Voxel Model that way, by meshing them all together by loading the voxels into their respective positions. So the side views would go from front to back, the front and back views would go from left to right (like how they are now). So theoretically the sprite would be 3D. The only problem is it would be hollow on the top and bottom so you really couldn't have more than 4 Degrees of Freedom or at least not let the player see on top of the model. With something like Wolf3D that wouldn't be a problem, but something like DooM where you can be above a player/monster that would be ugly. :D
Anyway, the modeller with the "Depth Colouring" method it give you a good head start, but I still think there would have to be some degree of tweaking by hand. Especially since I'm no master coder like Ken. :D
Another alternative which is more simple and not really pushing the boundaries of anything like we're discussing is, just use a tweaked "Depth Colouring" method and just change the voxel sprite view for different viewing angles.
I'll try and hack together a multi-view composite method tonight or tomorrow. I'm really interested in seeing what 0xC0DE came up with, because I'm running out of ideas. :D
EDIT: LATER ON...AGAIN! Well, I tried the Mutli-view composite method of which I spoke today. Yeah, it didn't work out so well. It turned out more like a rectangle with different voxel views on it.
I think I've hit my plateau though, I'm out of ideas. I'm gonna take a break for a little while and work on my Polygon Software Engine, I did do some work on it today, got Flat Shading and Transparency (which coincidently the method I thought of is the same method used by the beloved Sega Saturn in most games except Burning Rangers).
So we'll have a pow-wow and figure out what we're going to do next.
Edited by Jinroh at
Awesoken at
I just created some voxel converters for EveryGraph's Voxel3D formats:
v3b2vox.exe converts V3A/V3B to VOX vox2v3b.exe converts VOX to V3A
Download here: http://advsys.net/ken/util/v3b2vox.zip (Source and exe, 9KB total)
Interestingly, V3B is nothing more than V3A with deflate (ZIP) compression applied. The hint came from the first byte of the file: 0x78, which means: 32KB sliding buffer / method #8 in the deflate spec : )
0xC0DE at
I decided to release the source for my spr2voxel demo, hopefully it's helpfull. :)
I'm still working on a 'full' 3d voxel model demo though.
Edited by 0xC0DE at
Ghostpilot at
Thank you for the sources to all new toys. It will be fun to read and learn from them.
DooMAD at
Hi. Ghostpilot just pointed me towards this thread. I'm quite pleased now, since the developments here will certainly help the progress of the Doom Voxel Project.
Awesoken said at
Is there a download for the Doom voxel project models? If I could get my hands on some good test models, that might be enough to motivate me to add support to Slab6 : )
All the voxel models I have are available here: http://www.teamhellspawn.com/voxels.zip
The various people who made them are credited here
I'll do some work on the Doom Voxel Project page tomorrow to add a downloads section for both *.vox and *.v3b formats.
Edited by DooMAD at
Ghostpilot at
Voxel3D has a nice GUI but "mixed content" under the hood. If slab6 was a tad bit more user friendly and more "in phase with the current decade" it would be the natural choice.
Still... The DooM Voxel project did start in the wrong end of the pipeline. We produce voxel models when it doesn't exists a doom port today that can render voxel models, regardless of file format.
That small little detail doesn't stop us from pursuing our goal though.
Jinroh at
Hey all,
I'm still useless at this point voxel-wise. I've not thought of a decent way of taking 3-4 BMPs and using some composite interpolation method to make them a Voxelized Object. So in the meantime I've been working on my Polygon Engine.
However, I do have some code that I found a while ago that may be of some use to you.
It is a Voxel Modeller written in Qbasic by somebody, I couldn't find their name in their code. So...if the author happens to come by here zip me your name and I'll put it down here. I originally based my voxel modeller idea off of this one, but I had a more intuitive interface planned for mine.
Anyway, the link is http://www.geocities.com/solardarkmagician/VoxelModeller.zip It has the QB source and everything but Qbasic itself to run the program. QB 3 or 3.5 I think is what I ran it on and it worked fine. QB-4.5 Doesn't work very well if I recall correctly. I have 3.0 or 3.5 and 4.5 but I know 3.0 or 3.5 works fine.
Hope that helps! Ciao!
Awesoken at
Google "space carving", and you'll find some papers describing algorithms that are much more powerful than what I hacked up in SLABSPRI. To be honest, I never fully understood their algorithms, at least not to a degree where I could start implementing.
Also, is SLAB6 really that hard to use? You guys have spent more time looking for an alternative, when you could have been learning how to use SLAB6 - which really isn't hard once you know a few keys. Yes, it has no menus and buttons. Note: I plan to add them soon : ) To save you time, here's a SLAB6 cheat sheet, containing the most important controls:
Arrows&mouse: move/turn/etc.. Insert/Delete: Add/Remove cube Home/End: Add/Remove cubes (faster) Tab/Space: Grab/Plot color Alt+Space: Plot color (thicker) 'L'/'S': Load/Save KVX 'R', '.' on the keypad: Toggle shading modes. Default shading is better for viewing. Use these to make editing easier.
Jinroh at
Wow Ken...that's some complex stuff.
I looked up some of the papers on "Space Carving", they didn't seem very useful, there wasn't a whole lot there on the algorithm. Just who did what in what years and who gets credit for X and Y. I can see why you never fully understood the algorithm, there's not a whole lot there (that I found anyway). So I don't have a snowball's chance in Hades of understanding it. :D
I've used Slab6 a few times, but never really got the hang of it. Then again it took me from like Middle school until like last year to get used to Milkshape3D :P that's like 7 years. Granted I only tried using it for like 2-3 of those years, but still. Now I'm at least somewhat competent with it. I've seen a lot of people make some really sweet models with Slab6, but I'm not very good with tools I guess. My brother now, he could probably make some awesome stuff with it. He picked up Milkshape and Blender like they were nothing.
I don't think they are really not wanting to use Slab6, I just think since Hugo and myself are doing some Voxel experiments of our own we might come up with something useful. Though, I've about hit the limit of my usefulness. So the ball is in Hugo's court now.
Thanks again for the info Ken, I'll keep checking out the "Space Carving" algorithm and see if I can find anything useful.
Maren at
Awesoken said at
Also, is SLAB6 really that hard to use?
Not at all, it's simple, small, fast and efficient like the rest of your apps, but I could use some nice 3d grid as guide :)
Ghostpilot at
Jinroh: Did you get any luck when trying the angle->sprite version? How about do depth-colour-method on two sprites (of the same object of course) from two angles and then combining them?
Maybe it's enough to inflate the front sprite and the side one for getting a so-so good contour shape.
Ken: When slabspri did primitive carving from angeled sprites and chose colour. Did it mix colours for the voxels recieving colour from two sprites. (corner voxels)
Devan at
DooMAD said at
Hi. Ghostpilot just pointed me towards this thread. I'm quite pleased now, since the developments here will certainly help the progress of the Doom Voxel Project.
Awesoken said at
Is there a download for the Doom voxel project models? If I could get my hands on some good test models, that might be enough to motivate me to add support to Slab6 : )
All the voxel models I have are available here: http://www.teamhellspawn.com/voxels.zip
The various people who made them are credited here
I'll do some work on the Doom Voxel Project page tomorrow to add a downloads section for both *.vox and *.v3b formats.
I thought that project was dead :)
Awesoken at
Ken: When slabspri did primitive carving from angeled sprites and chose colour. Did it mix colours for the voxels recieving colour from two sprites. (corner voxels)
Yes. Visit http://advsys.net/ken/build.htm, and look for "How does SLABSPRI convert images to voxels?"
Ghostpilot at
Devan said at
I thought that project was dead :)
It's a small but very much significant difference between dead and not so active.
Jinroh at
Jinroh: Did you get any luck when trying the angle->sprite version? How about do depth-colour-method on two sprites (of the same object of course) from two angles and then combining them?
Maybe it's enough to inflate the front sprite and the side one for getting a so-so good contour shape.
Yeah, I thought that might be a good idea too Ghostpilot, but still no go. It still looks too blocky. I haven't forgotten about the project, that's not the case, it's still cooking in my brain, I've just been job-hunting and stuff so it's been crazy. I'm asking some people about their thoughts as well so hopefully I can think of a better way of doing this compilation technique.
Sorry for keeping you hanging for so long.
Ghostpilot at
Jinroh said at
Sorry for keeping you hanging for so long.
No worries. It's just of general intrest I'm asking. Itäs not like I'm waiting by the computer inapatiently for an answer. :-)
Jinroh at
Itäs not like I'm waiting by the computer inapatiently for an answer. :-)
Well, that's good, I'm still thinking about how to do this. Nothing has really worked well yet. ^_^ But I'll think of something.
0xC0DE at
Hi, I changed my name from 0xC0DE to my real name : Hugo Smits. Anyways;
Sorry for the late reply. But I had a lot of school work (end of the year stuff). Now that I finished all work, I though I’d deserved a little freetime to finish the voxel stuff. And So I did. And here it is :
Voxel Viewer 1.0
http://www.tremorsoftware.eu/meuk/voxViewer.gif
It renders fully 3D voxel models made out of 2D bitmaps (from different angles; side, top and front).
As you might notice it has some clipping bugs and stuff. I hope to fix them soon. But for now I’m quite satisfied with the result (it runs faster then I thought).
Also notice that the example sphere has some gaps, most of them are because of the texture itself rather than a bug.
Also note; I plan to write a tutorial about this in the very near future.
0xC0DE at
okay, tried some new models :
http://www.tremorsoftware.eu/meuk/voxelviewer.PNG
Some bugs that need to be fixed :
sortedSlices : there needs to be some kind of function that sorts the voxel slices on depth (so they will be drawn in the right order).
Clipping : there are still some visible clipping bugs.
Coloring : I need to make it a little bit more correct with the different sides. The models I’ve tried all turned out correct. But I can imagine some models that won’t. So obviously I’m going to try and fix that.
As you might notice, the rocket has more angles in the bitmap. But that’s pure for coloring (the barrel is round, so the front,back and side look the same.. so I can use only 1 angle for coloring).
To chop out the right model I only use the top 3 bitmaps : top view, side view, front view.
hunter551 at
This might sound dumb but what do i do with a dba file?
0xC0DE at
it's a GBA file. It stands for GameBoy Advance. So it's a GameBoy Advance rom file, you can run it in any major GBA emulator if you want.
I mostly program new algorithms for the GBA first, because that's the system I feel most comfortable working with.
Jinroh at
Awesome stuff Hugo, you beat me to the punch. :D
I've not actually gotten to work on it in a while though work takes up all my time now, I'm like a zombie half the time.
The renderer looks great. I can't dl it here at work, but I'll check it out at home and give some more feedback then. Did you use like a heightmap type method or a compilation, out of curiosity?
Congrats on the awesome work Hugo.
Edited by Jinroh at
0xC0DE at
Hey Jinroh,
I know what you mean, been busy with a lot of other stuff too recently. picked the project up just a few days ago, I really wanted to solve the problem ;)
Here are some new samples from my latest version. The only real problem is the coloring, clipping,etc is all working now :)
Next to the screenshots are the bitmaps I use to chop the model out. I use 3 angles for chopping. Top, Side and front (in that order).
I just check if a pixel matches on all three angles, and if there's a exposed side of the pixel/voxel (otherwise it's closed in and not visible, and thus not for drawing).
But I don't really have a good solution for the coloring (which color from which angle I should use). You can cleary see that in the sphere demo.