Voxlap library released! Don't all download at once : ) This package is meant primarily for game developers (programmers, artists, level designers, etc..).
ShadowX at
LOL, that's hilarious. I just found out about it today, and was wondering when it was going to come out. Ken you're the man, I've been working on Voxel stuff in my spare time forever and just haven't had the resources to dedicate to get anything real done. I had some real gay stuff back in high school (on my killer 486!) but everyone was looking at polygons as the way to go. I'm definitely going to start focusing more on voxels, with hardware acceleration, we can probably start doing some pretty serious stuff. (I'm so optimistic!)
ShadowX at
BTW, you're the man. You motivated me and my friends into game development when we were playing Duke3D back in High School.
Frobozz at
Just downloaded it and ran voxed. Easy to figure out without having to read the documentation.
I just finished posting about the library on another forum so you might get plenty of downloads. Or maybe not considering only a few C/C++ users frequent that site. Maybe I'll post about it on a C/C++ forum or two. :wink:
Edit: Does it compile under Visual C++ .NET? Or do we need a previous version?
Hazard at
Wow, can't wait to get home from work and try it out! *worships godlike ken* ;)
Calypso at
Can I use it in another compiler like dev-C?
Frobozz at
Good question. I think there is a download of DirectX for DevC++. Here are instructions from GameDev: http://www.gamedev.net/reference/articles/article2067.asp
There is also a DirectX 8 package available under the Packages section of Bloodshed's website.
Awesoken at
Sorry, it only compiles under Microsoft Visual C. I have no plans to support other compilers at this time. I noticed some linker problems when using VC Toolkit 2003. To fix the error with "ftol2", add /QIfist to the list of compile options on line 3 of GAME.C. Using this switch can be dangerous because it causes rounding to work differently from the C standard, but in my example program, it seems to work ok. Also, to remove the "deprecated" warning, change all "/G6fy" in the makefile to "/G6Fy".
Frobozz at
Awesoken said
Sorry, it only compiles under Microsoft Visual C.
Well you know where you can work if you ever need a job. Microsoft! That one line might get you a job. :lol:
Just for fun I think I'll try to compile it under MinGW. Never hurts to try though (unless the hurt process extends to Windows causing a permanent crash). :wink:
Calypso at
ha, yeah, I guess I will try it then.
ShadowX at
Have you considered throwing some sort of hardware support in there?
Awesoken at
A better question would be:
Has hardware considered throwing some sort of voxel support in there?
Once Nvidia and ATI get around to doing their part, I'll do mine. Until then, I'll be concentrating my efforts on optimizing for Intel (and to a lesser extent, AMD).
cragtek at
Awesoken said
A better question would be:
Has hardware considered throwing some sort of voxel support in there?
Once Nvidia and ATI get around to doing their part, I'll do mine. Until then, I'll be concentrating my efforts on optimizing for Intel (and to a lesser extent, AMD).
I have to admit my knowledge on this subject isn't particularly great, but what's the difference between point sprites and voxels? I say this as I noticed point sprites are benchmarked on 3DMark2003, which implies they have hardware support. The spinning horse looks very voxel-esque.
-C
Awesoken at
Point sprites work very much like the "bounded cubes" mode in SLAB6, or standard sprites in Voxlap. Basically, it's a library routine in OpenGL/DirectX which draws a list of small rectangles or varying sizes. Point sprites can be used to draw the individual voxels of sprites, but they're completely useless for raycasting methods.
Unfortunately, all my tests have shown that point sprites are slower than my own software routines. Not only that, I found that drawing texture-mapped cubes in hardware was still faster than point sprites. I don't know the reason for this. If you want to convince me that point sprites are worth it, then all you have to do is send me a demo that renders more voxels per second than SLAB6 on the same machine. (If you succeed, please specify hardware.) Until that happens, "point sprites" will be nothing more than a marketing buzzword to me.
AcetoliNe at
I went to your site, scrolled to the updates section, and....
almost creamed when I saw it!!!!
VOXLAP LIBRARY RELEASED!!!!
I'm gonna have some fun with this baby!
AcetoliNe at
A better question would be:
Has hardware considered throwing some sort of voxel support in there?
Once Nvidia and ATI get around to doing their part, I'll do mine. Until then, I'll be concentrating my efforts on optimizing for Intel (and to a lesser extent, AMD).
You're absolutely right. It's time for hardware developers to include SOME kind of voxel support.
When you think of it, voxels would be SO easy to implement in hardware, and if implemented correctly, would also be very fast.
I guess the reason for not doing it is lack of consumer demand... but judging by this forum, that doesn't seem to be an issue :D
Anonymous at
I 'm interested in the type of hardware support you propose for voxel rendering. Rendering millions of cubes per frame?
great hw support would be if the "slicing" could be accomplished by the hardware.
if chip manufactors really change their opinion on rendering, then they should move to raytracing, not focus too much on voxel rendering.
Sebastian
AcetoliNe at
Well, first of all, voxels can be rendered in parallel. It is possible to do many voxels at a time because if you select correctly, the voxels will be independent of each other. So, If you come up with a hardware circuit to render voxels, then you can just duplicate it and the rendering time will be halved.
Also, lines of similar pixels (which often happen in the renderer) could be greatly speeded up in hardware.
Plus, you always have the advantage of freeing up the processor to do other things (animation, etc...)
deps at
This is so cool that I don't know where to begin! :D
Thanks a lot Ken!
JoshW at
Hey ken, say if we have a lesser powerful cpu such as a celeron A, would it be possible for me to get it running on my computer with significate changes to the assembly, or is there a lot of it in the libs, which i obviously couldn't work on (or could i...)
Oh and while on the subject, you said that you made changes to Evaldraw to allow it to work on PentiumMMX+'s, but it freezes my computer when i ran it. Complete freeze, no keyboard, no mouse, reach for the power switch. That isn't right.
I was thinking this would be an invalid instruction exception, which then a nasty windows-error box would pop up, but this hasn't popped up before when it was :(
Phoenix at
my brother's computer which is a celeron 1.7 runs both the cavedemo and the voxlib executables perfectly. on the other hand, my computer which is also a celeron of SIGNIFICANTLY crappier stature, doesn't run any of them whatsoever.
Awesoken at
I tested EVALDRAW on a Pentium 200 MMX and it crashed only in the voxel modes (x,y,z,...). It never froze on me, so I don't know what that's about. I fixed that bug and just finished posting a new version on my website. Thanks for the tip.
I suspect Celeron A is equivalent to a Pentium II in terms of instruction set. Voxlap does not run on a Pentium II. I do have some #ifdef's in my code that would make it run, but doing this would totally destroy the quality of the engine. Not only would I have to disable practically all assembler code, but you would also lose the Z-buffer (for sprites), and any kind of lighting. Sorry, but I won't be supporting a Pentium II version of Voxlap - ever. It's time for you to upgrade.
Awesoken at
I moved the discussion about upgrading hardware here. It doesn't belong in the "Voxlap released" thread.
Hotte at
Awesoken said
... Not only that, I found that drawing texture-mapped cubes in hardware was still faster than point sprites. I don't know the reason for this ...
Points and wireframe are regulary not beeing accelerated by the vga hardware. Only a hand full of vga devices support those stuff (nVidia Quadro series and FireGL for example). Thats the reason why every 3d mesh editor slows f(/&3ing down when you switch to wireframe mode.