0 Members and 1 Guest are viewing this topic.
Thanks for the help !Quote from: Builderboy on September 27, 2012, 01:34:39 pmFirst off, it is important to note that whenever the camera is within a voxel, the voxels that are rendered are sorted relative to the distance they are to that voxel. Consequently no matter what voxel the camera is in, the order of the rendered voxels is always the same relative to the center camera voxel. What this means is that you can presort a large number of voxel positions into an array based on how far they are from a center voxel, and simply use those positions relative to the camera to render.Seems interesting. Could you give an exemple ? Because of my poor English skills, I'm not sure that I've got it very well...Quote from: Builderboy on September 27, 2012, 01:34:39 pmThis works, but it can take up a large amount of memory. If that is a problem, there is another solution that I discovered when working on my Castle Storm game, which uses a similar rendering method. The way it would work is by drawing the voxels (still relative to the camera position) in shells, and it is painfully difficult to explain, so if you are interested, I can whip up some sort of gif or example and we can talk from thereMemory isn't a big problem on the TI-Nspire. i can achieve full world renders, which means that I use an array containing more than 30,000 floats...Quote from: Builderboy on September 27, 2012, 01:34:39 pmNow, this would speed up the sorting of cubes, but it would not actually speed up the drawing, which is probably another main bottleneck. First off, since you are only rendering cubes, you can always discard the faces that are facing away from you. This is a rendering trick you can use on convex objects, that any faces that are facing away from you cannot actually be seen. Additionally, you can use a simply dot product to detect whether or not a face is facing away from you, so it is super speedy and results in half of your faces being discarded!I already do that Quote from: Builderboy on September 27, 2012, 01:34:39 pmAnother method would be to look at the cubes surrounding a cube to be rendered. When you go to render a cube, you can look at neighboring cubes to see if they are solid, if not, you do not have to render the connecting face! This should result in significant speedups hopefully, since using these methods would drastically cut down on the number of polygons you need to render in any given frame. This could improve my drawing function indeed, since I draw every cube that "touches" an empty block...By the way, I added a function to render full world with F.You now can see your creations properly Full renders take about 5 secs to generate...But as I said, I use more than 30,000 floats, so I'm afraid that it might crash grayscale Nspires, which don't have so much RAM. (it doesn't crash the grayscale emulator, though)
First off, it is important to note that whenever the camera is within a voxel, the voxels that are rendered are sorted relative to the distance they are to that voxel. Consequently no matter what voxel the camera is in, the order of the rendered voxels is always the same relative to the center camera voxel. What this means is that you can presort a large number of voxel positions into an array based on how far they are from a center voxel, and simply use those positions relative to the camera to render.
This works, but it can take up a large amount of memory. If that is a problem, there is another solution that I discovered when working on my Castle Storm game, which uses a similar rendering method. The way it would work is by drawing the voxels (still relative to the camera position) in shells, and it is painfully difficult to explain, so if you are interested, I can whip up some sort of gif or example and we can talk from there
Now, this would speed up the sorting of cubes, but it would not actually speed up the drawing, which is probably another main bottleneck. First off, since you are only rendering cubes, you can always discard the faces that are facing away from you. This is a rendering trick you can use on convex objects, that any faces that are facing away from you cannot actually be seen. Additionally, you can use a simply dot product to detect whether or not a face is facing away from you, so it is super speedy and results in half of your faces being discarded!
Another method would be to look at the cubes surrounding a cube to be rendered. When you go to render a cube, you can look at neighboring cubes to see if they are solid, if not, you do not have to render the connecting face! This should result in significant speedups hopefully, since using these methods would drastically cut down on the number of polygons you need to render in any given frame.
hm I get a crash when I press F sadlyti-nspire CX OS 3.1.0
Is there a jump key?
This is great.Also seconded on the saving. Even if it's just a savestate or something, it'd be worth it
Is there a reason you use double instead of float? If you don't really need the extra precision, you can go with float and use half the space (and probably less processing time too)
Because Augs said that the current ones are inconvenient...
Also, is an inventory being planned?
Author
Topic: nCraft (3D minecraft-like game for the nspire) (Read 113834 times)
