Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (726)
Games in Android Showcase (216)
games submitted by our members
Games in WIP (796)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2
1  Game Development / Newbie & Debugging Questions / Re: Lwjgl 3 - difficulties trying to use VBO's on: 2017-05-23 14:56:26
Thank you everyone for helping!  Smiley

@Riven, I followed the examples in that link, and got it to work. Thanks for the link Smiley
@Elect Thanks for pointing that out, I'm now using colors the way those examples do rather than glColor3fv.
@Princec, those examples were just to show the results of attempting the suggestions, I converted the linked lists to arrays once I followed the link's example and got the code to work. I will keep that 2nd aside in mind for future projects I do, but for this one, the majority of the project is to do the projection manually and only feed lwjgl the 2d screen coordinates.

Here's the code that I put together closely following the link example,

            bufferLen = 0;
            colorLen = 0;
            glClear(GL_COLOR_BUFFER_BIT);
            painterQueue.paint(this); // this fills out vertexArray and colorArray, and increments bufferLen and colorLen
            painterQueue.drawReady = false; // to indicate to engine thread to we're ready to draw another frame
            
            vertexBuffer.clear();
            vertexBuffer.put(vertexArray).flip();
            colorBuffer.clear();
            colorBuffer.put(colorArray).flip();
            
            glEnableClientState(GL_VERTEX_ARRAY);
            glEnableClientState(GL_COLOR_ARRAY);
            
            glColorPointer(3, GL_FLOAT, 0, colorBuffer);
            glVertexPointer(2, GL_FLOAT, 0, vertexBuffer);
            glDrawArrays(GL_QUADS, 0, bufferLen / 2);
            
            glDisableClientState(GL_VERTEX_ARRAY);
            glDisableClientState(GL_COLOR_ARRAY);

            glfwSwapBuffers(window);
2  Game Development / Newbie & Debugging Questions / Re: Lwjgl 3 - difficulties trying to use VBO's on: 2017-05-18 15:01:45
Because I'm projecting the 3d world coordinates to 2d screen coordinates myself. Hence, since the camera moves every frame, the vertices will be modified as well.
Is this indicative that I'm approaching this the wrong way? I.e., if I'm modifying all vertices every frame, should I not be using vbo's?
3  Game Development / Newbie & Debugging Questions / Re: Lwjgl 3 - difficulties trying to use VBO's on: 2017-05-18 14:04:09
By once per execution, I mean it will execute on initialization or first frame, but no more.
By once per frame, I mean it will be executed on each iteration of the game/draw loop
4  Game Development / Newbie & Debugging Questions / Re: Lwjgl 3 - difficulties trying to use VBO's on: 2017-05-17 14:59:54
@abcdef, per your suggestion, I've moved the floatBuffer creation to once per execution instead of once per frame, and just do .clear each frame. Likewise moved the int vboID = glGenBuffers(); line to once per execution instead of per frame.


        // once per execution
   FloatBuffer verticesBuffer = BufferUtils.createFloatBuffer(1000 * 100 * 10);
   int vboID = -1;

   public void oncePerFrame() {
         x = new LinkedList<>();
         
         glClear(GL_COLOR_BUFFER_BIT);

               // here i loop over polygons and add vertices to x.
         
         float[] y = new float[x.size()];
         for (int i = 0; i < y.length; i++)
            y = x.get(i);
         
         if (vboID == -1) {  // once per execution
            vboID = glGenBuffers();
            glBindBuffer(GL_ARRAY_BUFFER, vboID);
         }

         verticesBuffer.clear();
         verticesBuffer.put(y).flip();
         glEnableVertexAttribArray(0);
         glBufferData(GL_ARRAY_BUFFER, verticesBuffer, GL_DYNAMIC_DRAW);
         glVertexAttribPointer(0, 2, GL_FLOAT, false, 0, 0);
         glDrawArrays(GL_QUADS, 0, y.length);
         
         glfwSwapBuffers(window);
      }

And did not see any improvements.

I feel bad for posting prior to having a chance to reading Riven your link, but just wanted to try and provide update on the suggestions. I'll be reading that as my next step.
5  Game Development / Newbie & Debugging Questions / Re: Lwjgl 3 - difficulties trying to use VBO's on: 2017-05-17 03:56:48
Thank you both. I'll look at that intro and see what happens.

@Elect, just to clarify, you mean something like the following?

float[] accumulatedVerticies; // reset empty at beginning of each frame

void oncePerPolygon(float[] verticies) {
  glEnableVertexAttribArray(0);
  glVertexAttribPointer(0, 2, GL_FLOAT, false, 0, 0);
  glDrawArrays(GL_QUADS, 0, vertices.length);
  // accumulatedVerticies = accumulatedVerticies . append . verticies;
}


void oncePerFrame() {
  FloatBuffer verticesBuffer = BufferUtils.createFloatBuffer(accumulatedVerticies.length);
  verticesBuffer.put(vertices).flip();
  int vboID = glGenBuffers();
  glBindBuffer(GL_ARRAY_BUFFER, vboID);
  glBufferData(GL_ARRAY_BUFFER, verticesBuffer, GL_DYNAMIC_DRAW);
}

If that's what you mean (though I have a feeling I misunderstood you), I could just move all but the last line of the oncePerPolygon into the oncePerFrame, and just have the oncePerPolygon create append to the accumulatedVerticies, right?

Well, I just tried that, having the following execute once per frame:

         x = new LinkedList<>();
         
         // here i loop over polygons and add vertices to x.

         float[] y = new float[x.size()];
         for (int i = 0; i < y.length; i++)
            y = x.get(i);
         
         FloatBuffer verticesBuffer = BufferUtils.createFloatBuffer(y.length);
         verticesBuffer.put(y).flip();
         int vboID = glGenBuffers();
         glEnableVertexAttribArray(0);
         glBindBuffer(GL_ARRAY_BUFFER, vboID);
         glBufferData(GL_ARRAY_BUFFER, verticesBuffer, GL_DYNAMIC_DRAW);
         glVertexAttribPointer(0, 2, GL_FLOAT, false, 0, 0);
         glDrawArrays(GL_QUADS, 0, y.length);
         
         glfwSwapBuffers(window);

And the result was the same 1-3 fps at just a 1000 polygon count.
Yes vertices change every frame, since these are not 3d world coordinates, but the 2d screen-projected coordinates.
6  Game Development / Newbie & Debugging Questions / Lwjgl 3 - difficulties trying to use VBO's on: 2017-05-16 15:31:44
Intro, so I've spent a couple days trying to figure out the lwjgl 3 way of doing things with vbo's. This being the first time I'm hearing a lot of the terminology isn't making the resources/tutorials easy to understand. Nor do I want to begin at the very beginning, since I have a solid understanding of 3d rendering (though not of opengl or gpu's). Also, though I would like to take the time to learn opengl thoroughly eventually, at the moment, I just want to get my little experiment working.

Previously, I had been using Java graphics2D to draw polygons; e.g.,  brush.drawPolygon(xy[0], xy[1], xy[0].length);

However, I was not happy with the 15fps it was dipping too when polygon count would reach 15-20k. So I decided to try out lwjgl. Here's some code snippet I copied from a previous project before lwjgl 3 had come about, and was very happy with performance,
            glColor3fv(color);
            GL11.glBegin(GL11.GL_POLYGON);
            for (byte i = 0; i < vertices.length; i += 2)
               GL11.glVertex2d(vertices, vertices[i + 1]);
            GL11.glEnd();

But for learning's sake, I wanted to get a little familiar with the newer way of drawing in opengl. So I tried figuring out from tutorials and the online reference and eventually arrived at this working snippet (not included in the snippet is a glclear and glfwSwapBuffers that each happens once per frame):
            glColor3fv(color);
            FloatBuffer verticesBuffer = BufferUtils.createFloatBuffer(vertices.length);
            verticesBuffer.put(vertices).flip();
            int vboID = glGenBuffers();
            glEnableVertexAttribArray(0);
            glBindBuffer(GL_ARRAY_BUFFER, vboID);
            glBufferData(GL_ARRAY_BUFFER, verticesBuffer, GL_DYNAMIC_DRAW);
            glVertexAttribPointer(0, 2, GL_FLOAT, false, 0, 0);
            glDrawArrays(GL_QUADS, 0, vertices.length);

Unfortunately, this last snippet, was dropping painfully slow even at 1000 polygon count, which was disappointing, but also indicated that must not be the correct way of doing things.
I'm not sure if I can group up all my draw's into 1 giant array and only call glDrawArrays once, since I think only the last glColor would then be applied to all the quads. Nor do I want to include the color per vertex, since doing so seems to require writing a shader or something, and that seems like overkill for my requirement.
Additionally, if it matters, vertexes are in 2D coordinates. I do the 3d -> 2d transformation and lighting -> color calculations with java+math rather than opengl. Hence my reluctance to write shaders or anything too complicated.

Thanks,
7  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-12 14:47:03
Runtime terrain generation is fully functional now. This includes structures that span multiple chunks (in this video for example, there are towers that cross over 1 chunk boundary into another chunk boundary). Terrain chunks are 20x20x20, drawing chunks are 5x5x5. Terrain chunks are generated as your character moves into them, with a 2 chunk buffer around the character. So if you're at coordinate 30,30,30, then the chunk you are in (1,1,1) is generated, and 2 chunks around it (chunks 0,0,0 to 3,3,3 inclusive) are also generated.
World is not infinite, but is 10,000 x 10,000 x 200 squares big. The only limitation on how large the world is is how small the drawing chunks are. The smaller the drawing chunk size, the larger the initial array has to be (currently, generating the 2000x2000x40 draw chunks takes 2 seconds upon starting the app). Increasing the drawing chunk size allows faster initialization or larger world, however, slightly decreases fps (5x5x5 seems optimal at this clutter density).
Also added wire drawing mode (press / to toggle between normal, wire only, and normal + wire).
Next steps is to make it slightly prettier (Any suggestions how to do so are very welcome). Some ideas I have are to draw borders/edges (like cell shading except not shading, just the edges), some ambient sky, some ambient music, some particles when you shoot the grappling hook.

jar (v4): http://www.java-gaming.org/user-generated-content/members/244457/kami4.jar

<a href="http://www.youtube.com/v/d--bDxh8Org?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/d--bDxh8Org?version=3&amp;hl=en_US&amp;start=</a>

<a href="http://www.youtube.com/v/Xs7kDuIcpno?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/Xs7kDuIcpno?version=3&amp;hl=en_US&amp;start=</a>
8  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-09 04:03:04
The first steps towards runtime terrain generation.

<a href="http://www.youtube.com/v/G7m-0JDIU-o?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/G7m-0JDIU-o?version=3&amp;hl=en_US&amp;start=</a>
9  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-06 14:30:59
Thanks Smiley

It takes about 12,000 particles on my laptop until fps starts dropping sub 20. Keep in mind each cube drawn is only a few algebraic expressions and 3 fill polygon calls, so not that expensive. Essentially, screenX = x perpendicular to camera normal / distance from camera, screenY = y perpendicular to camera / distance from camera, so the math is not computationally heavy at all. It's more the traversing the world grid that takes time.

Even the following code snippet takes 0.03970144 seconds (that's 25 fps). So if I need to stay 50+ fps, I need to double performance, either by minimizing the amount of unnecessary world grid traversal, or by making sure each grid location traversed takes less time than computing i * j / k takes. Since the second solution isn't going to happen, i.e. each grid traversal is defiantly going to involve more than 1 double multiplication and 1 double division, minimizing how much of the world is traversed each frame becomes big priority.

1  
2  
3  
4  
5  
6  
7  
8  
9  
System.out.println("Begin timing");
      double time = System.nanoTime();
      double x = 0;
      for (int i = 0; i < 400; i++)
         for (int j = 0; j < 400; j++)
            for (int k = 0; k < 50; k++)
               x += i * j / (k + 1.1);
      double etime = System.nanoTime();
      System.out.println("end timing. time: " + ((etime - time) / 1000000000L) + " ... x: " + x);


That's a 400x400x50 = 8,000,000 iterations.
Since max draw distance is set to 163 with the current fog configuration, using simply a "traverse only world coordinates x-163 to x+163, and y-163 to y+163, and z-163 to z+163", would be 34,645,976, would be 4.330747 more iterations. So it becomes apparent, that we need smarter algorithm (8.7 times smarter) to get 50+ fps. Hence, my prior project Ot (which this project builds off of), which tried to optimize fps given large but sparse world. So the fact that we're using Java2D isn't that much of a hinderance since fill Polygon isn't the bottleneck. In my prior project (Conxeline which optimized for small but very dense worlds like minecraft underground), the world traversal was much less of an issue, and yes switching to JOGL and LWJGL each gave about double the performance as Java2D.
10  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-06 02:19:00
Here are videos of the latest build which should have flickering fixed.

.jar (v3) http://www.java-gaming.org/user-generated-content/members/244457/kami3.jar

grappling hook
<a href="http://www.youtube.com/v/NVmEy0zmtOA?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/NVmEy0zmtOA?version=3&amp;hl=en_US&amp;start=</a>

particles
<a href="http://www.youtube.com/v/lP_OfwwcZcQ?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/lP_OfwwcZcQ?version=3&amp;hl=en_US&amp;start=</a>
11  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-06 01:46:12
yes, wait(10) is just a wrapper for Thread sleep, because I didn't like the try catch polluting the main loop and because it's used twice. I didn't even realize it was not a good name choice until you pointed out it's name is shared by the Object.wait, I'll be sure to rename it.

1  
2  
3  
4  
5  
6  
7  
static void wait(int howLong) {
      try {
         Thread.sleep(howLong);
      } catch (InterruptedException e) {
         e.printStackTrace();
      }
   }
12  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-05 14:43:18
Quote
call painter.paint() directly, remove the graphics parameter and use the graphics object of the Frame that the painter inherits.
Yep that fixed it, thank you Smiley. Yes, the code on github, only uses 1 buffer; using multiple buffers was just to highlight the issue.

I'm not sure what you mean by:
Quote
Don't wait at the end of the loop.


When trying to use JFrame.getGrpahics, I see it is null prior to calling JFrame.pack(). At what point in time is the JFrame graphics object actually created? Is it safe to assume, it'll always be created after the pack() is called, or should I simply add a "if (g == null) g = getGraphics()" check to the top of my paint call?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
Painter(int frameSize, int imageSize, Controller controller) {
      FRAME_SIZE = frameSize;
      IMAGE_SIZE = imageSize;
      canvas = new BufferedImage(IMAGE_SIZE, IMAGE_SIZE, TYPE_INT_RGB);
      brush = (Graphics2D) canvas.getGraphics();
      getContentPane().setSize(FRAME_SIZE, FRAME_SIZE);
     
      System.out.println(this.getGraphics()); // null
      pack();
      System.out.println(this.getGraphics()); // sun.java2d.SunGraphics2D[font=java.awt.Font[family=Lucida Grande,name=Lucida Grande,style=plain,size=13],color=java.awt.SystemColor[i=9]]
     
      borderSize = getHeight();
      setSize(FRAME_SIZE, FRAME_SIZE + borderSize);
      setLocationRelativeTo(null);
      addMouseListener(controller);
      addKeyListener(controller);
      addMouseMotionListener(controller);
      setDefaultCloseOperation(EXIT_ON_CLOSE);
      setIgnoreRepaint(true);
      setVisible(true);
      frameBrush = this.getGraphics();
   }
13  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-05 02:39:25
so here's the drawing logic highlighted.

On initialization:
canvas = new BufferedImage(IMAGE_SIZE, IMAGE_SIZE, 1);
brush = (Graphics2D) canvas.getGraphics();

The loop is basically:

clear (brush.clearRect)
draw (a combination of brush.setColor and brush.fillPolygon)
repaint (JFrame graphics.drawImage(canvas))
sleep (10 ms)

http://pastebin.java-gaming.org/b63b74338511f

And it's flickering. I purposely put the sleep in between the draw and the clear so to make sure it had time finishing drawing before the canvas was cleared.
Increasing buffer count to like 10 definitely helps reduce the flicker but does not eliminate it. I feel like there's something wrong with the code if I need to use 10+ buffers to avoid flickering.
I'm sure there's something I'm missing, I'll keep looking at it, but if anyone notices something obvious, please let me know.

update:
I've noticed if I use new Color(0f, 0f, 0f, .1f) instead of Color.black when clearing the canvas, the flicker does not go away. Which indicates that it's not being caused by erasing the canvas prior to it  completing drawing to JFrame screen. It makes me think that maybe JFrame.repaint() does not guarantee to call JFrame.paint(Graphics) immediately / synchronously. I'll continue trying out stuff.
14  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-04 23:45:53
Yep, I understand. that's exactly what I was doing before this temporary fix. I'll give it another shot, and if I continue having issues, I'll post the actual relevant code and see if there's some issue I'm missing.
15  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-04 22:36:22
Actually, I was initially double buffering, but got into flickering issues, and ended up putting in a temporary fix, where it's constantly creating new buffered images every single frame. So it's weird that it still flickers. Though the bigger issue I'll look into is what I was doing wrong with double buffering in the first place.

I'm not sure why the fps would be affected this build. It may be because this build has a larger terrain map. This version terrain is 400x400x50. I believe, but need to confirm, previous build was 200x200x100, so terrain volume has has doubled.
16  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-04-04 14:46:28
new jar (v2): http://www.java-gaming.org/user-generated-content/members/244457/kami.jar

Awesome. I only get like 30fps on my laptop, so hearing that is a relief.


Here's a status update.
Major update is the addition of grappling hook (press shift or click the mouse button), it will shoot out to wherever your camera is pointing and pull the character towards itself once it's attached.
Also minor adjustments to smoke particles movement, terrain generation (higher structures, more tapered tops, and some random colors), and character physics. Also, the camera now has an adjustable height (adjusted with Z and X).


Next steps are to add run time terrain generation / infinite terrain. Some kind of demo game mode (like the lava idea or feel free to make suggestions). And maybe some sort of cell shading, which is going to be interesting since this is all cpu rendered, with no graphic libraries.


By the way, the character physics are governed by 3 lines of constants at the top of the character.Character class, so feel free to adjust them and play around and let me know what values seem to work nicely.
The character physics are basically vx/vy *= friction, vz = (vz - gravity) * friction. Collision damper is multiplied to velocities when you collide into the edge of structures or the ground. Jump acc determines how much to add to vz when you press jump. Run acc is how fast you move while on the ground; air run acc is while you're in the air (jetting or hooking); climb acc is for when you're climbing structures. Jump mult is multiplied to vx and vy when you jump. Hook speed is how fast the hook shoots out, hook friction 1 just means the hook does not slow down as it shoots forward, and hook gravity 0 means gravity does not apply to the hook. Hook acc determines how strongly the hook pulls the character towards itself once attached.

1  
2  
3  
   private static final double FRICTION = 0.9, AIR_FRICTION = 0.97, CLIMB_FRICTION = .99, GRAVITY = .05, COLLISION_DAMPER = .1;
   private static final double JUMP_ACC = .2, RUN_ACC = .1, AIR_RUN_ACC = .04, JET_ACC = .04, CLIMB_ACC = .055, JUMP_MULT = 1.5;
   private static final double HOOK_SPEED = .2, HOOK_FRICTION = 1, HOOK_GRAVITY = 0, HOOK_ACC = .05;



Also feel free to adjust the default terrain color (line 15 of terrain.terrainModule.FullGray class) and let me know what seems to work, because I'm not fond of the gray theme going on at the moment.
17  Games Center / WIP games, tools & toy projects / Re: Kami - Java 3D voxel platformer on: 2017-03-29 03:35:40
Thanks.

Sure. I've added the jar to dropbox (v1) https://www.dropbox.com/s/my35r1l0298b4g3/Kami.jar

Fair warning though, it is far from bug free. there's definitely issues with aiming the grappling hook when the camera is below the ground surface, or there's a building between the camera and your character. Also, the world is generated randomly every time it's ran, so if a structure spawns on top of you, you'll just have to restart the app.
18  Games Center / WIP games, tools & toy projects / Kami - Java 3D voxel platformer on: 2017-03-27 00:13:49
Latest jar (v4) : jar : http://www.java-gaming.org/user-generated-content/members/244457/kami4.jar
___________________________________________________________________________________________

Hello Smiley.
Here's my new project. It's heavily relying on the 3d voxel engine I built in my last project and is trying to make a 3D version of the grappling hook + jet pack demo I made in early 2015.

So far, just finished up the basic collision detection and movement. (wasd to move, tap space to jump, press down space while walking into walls to climb, and press down space to jet pack).
Short term goals will be to add the grappling hook, a mini game mode (floor is rising lava, get to the exit before lava rises too high), and adding particles for the jet pack smoke.

Feedback much appreciated.

Git hub in case someone would like to try it out: https://github.com/mahhov/Kami

<a href="http://www.youtube.com/v/RYF9sE0F-bY?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/RYF9sE0F-bY?version=3&amp;hl=en_US&amp;start=</a>
19  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-03-15 14:29:21
Here's a final video showing off how the engine handles some simple map (generated using the square and diamond algorithm).
There's also a pink block you may notice that's shooting out small projectiles every few seconds, it's the gun module.
Next steps if I continued to the project would have been to make the world destructible and collision detection and such.
However, I'll most likely be stopping working on this project as I've achieved all the goals I wanted to reach with it in terms of rendering optimizations and algorithms.

By the way, if trying to run the code in the git hub repository, there are 3 main methods, Engine.main will just run sandbox mode, EditorEngine.main will run just the editor mode, and Client.main will run them both (toggling back and forth via the 'm' key).

I'll update the top post to include the 2 latest videos.

Thanks guys for all the feedback.

<a href="http://www.youtube.com/v/Vuf5CngovKY?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/Vuf5CngovKY?version=3&amp;hl=en_US&amp;start=</a>
20  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-03-12 00:00:55
The visual editor is now complete. Here's a ~7 min demo. Feel free to try it out (via the github link, since I haven't updated dropbox link since the first post), and post your creations or private message your creations to me if you prefer.

Sandbox Controls:
w, a, s, d, space, and shift - accelerate ship forward, left, backward, right, up, and down
z, x - zoom camera in and out
move mouse - change camera orientation
p - pause
enter - toggle between free-camera (controlled by mouse movement) and follow-camera (always looks towards your ship)
m - to toggle between sandbox and editor

Editor Controls:
w, a, s, d, space, and shift - to move camera
i, j, k, l, u, o - to change selected direction
1, 2, 3, 4, 0 - to change selected piece (1=hull, 2=rotor/thruster, 3=helium, 4=blade/wing, 0=delete)
mouse move - to change selected location
mouse click - to place selected piece with selected direction at selected location
enter - to reset camera to default location and orientation
\ - to load ship from file
/ - to save ship to file
m - to toggle to sandbox mode and try out your creation! (be sure to save before going to sandbox mode. sandbox mode will load from file, not from whatever is in your editor)

<a href="http://www.youtube.com/v/5Nw9JopHREc?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/5Nw9JopHREc?version=3&amp;hl=en_US&amp;start=</a>
21  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-02-26 02:12:11
I've added 2 more components. Helium component which applies an up force, and a blade/wing component which demonstrates sub-cube geometry. Next steps to make a ship editor so they can be built and customized without writing lines of code.

I've also added a link to the github repo, https://github.com/mahhov/ot-voxel-engine

<a href="http://www.youtube.com/v/_M-LvFoPrGo?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/_M-LvFoPrGo?version=3&amp;hl=en_US&amp;start=</a>
<a href="http://www.youtube.com/v/0xAV5HDiWlw?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/0xAV5HDiWlw?version=3&amp;hl=en_US&amp;start=</a>
22  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-02-11 12:34:42
Here's a quick update of the new rotor components added. The ship is now modular, i.e. depending on how it's made up of hull and rotor components, it will have different mass, angular inertia, and acceleration. Next steps, adding a 3rd component (blades / wings) and then adding non-cubic shapes. Here's 2 different ship configurations:
<a href="http://www.youtube.com/v/Pi7JR8kDpIk?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/Pi7JR8kDpIk?version=3&amp;hl=en_US&amp;start=</a>
<a href="http://www.youtube.com/v/iijK48PYLCo?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/iijK48PYLCo?version=3&amp;hl=en_US&amp;start=</a>
23  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-02-04 00:08:54
Sure, using jogl or lwjgl would make it faster, but it doesn't really affect the code at all. Maybe later I'll just swap out Java2d for one of those.

I've completed controls; here's a quick video demonstration. Next step is to make the ship modular, as in built from different pieces such as hull, thruster, helium, etc.

<a href="http://www.youtube.com/v/gusWNdKVUiM?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/gusWNdKVUiM?version=3&amp;hl=en_US&amp;start=</a>
24  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-01-18 16:44:33
Yep, no zbuffer. Just a small update, trailing camera done. Next step, allowing user to control the ship.

<a href="http://www.youtube.com/v/2yQoAaePREA?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/2yQoAaePREA?version=3&amp;hl=en_US&amp;start=</a>
25  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-01-15 19:00:21
Added ships, i.e. moving cluster of blocks. There's graphical bug with some surfaces being drawn on top of other surfaces when they shouldn't be, but I hope to fix that soon.

<a href="http://www.youtube.com/v/fsdF4Uid7BM?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/fsdF4Uid7BM?version=3&amp;hl=en_US&amp;start=</a>
26  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-01-10 14:37:16
Shouldn't it be painfully slower? I'm impressed that you can do that heheh

For a  simple use case like this (i.e. no textures, hard shadows, gloss, reflections, etc) the most computationally heavy part with traditional rendering tends to be determining draw order (via z buffering for example). And one of the main trade offs of voxel rendering is that ordering becomes really computationally cheap at the cost of dramatically increasing the number of polygons you have to deal with. But that's where all these optimization algorithms come in, they all try to minimize the number of "qualified" polygons we have to consider. As for the actual drawing pixels on screen, I'm not sure whether graphics2d instructions still eventually get converted to graphics card instructions or whether they are completed by the CPU, but I do know for my previous rendering project, switching to jogl was only a 10 or so fps gain.
27  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-01-10 04:36:07
Yep pretty much. I'm calculating the screen location, color/shade, order of all the shapes needed to be drawn and just telling some graphics2D instance to drawPolygon / drawString.

I've been working on all the optimization algorithms lately, so haven't had much to show. But I'm pretty much done for now with optimizations, and added support for rotated cubes just to have something new to show.

If anyone's interested, here's an generic overview of the optimization steps I take. Feel free to add suggestions.
1) determine max draw distance (the distance after which even the brightest 1x1x1 object would be too dark / small to be noticeable anyways)
2) determine the coordinates of the minimum-bounding-axis-aligned-rectangular-prism encompassing the camera field of view.
3) iterate through these coordinates (left -> center, then right -> center, then center, so we don't have to worry about draw-order or zbuffering)
4) for each non-empty coordinate, check if it is within the camera field of view via a simple dot product and distance check (since the minimum bounding rectangular prism is larger than the fov, and since this check is very low-cost)
5) get the surfaces of that coordinate that have normals facing the camera (again via dot product)
6) convert the surface coordinates to screen coordinates. As a final check, make sure at least one of the surface's screen x,y coordinates are within [-.5, .5] and if so, draw it

On top of this, in order to support vast areas, with potentially low-density, the world is divided into chunks, so that chunks aren't initialized unless they contain at least one surface, and they are skipped over in the drawing algorithm if empty.

The only additional major optimization plan I have, I plan not to update (remove & add) surfaces as they move, unless they are in view. Instead, I'll "expire" the surface's old location via some counter, and add "trigger-points" bounding clusters of surfaces which move together so that the actual surfaces are added to the world only if the trigger points are visible.

Here's a new 30-sec screen-capture.

<a href="http://www.youtube.com/v/Oes6N6I4pjs?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/Oes6N6I4pjs?version=3&amp;hl=en_US&amp;start=</a>
28  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-01-04 05:25:46
Thank you all very much for the encouragement! Yes, the fps is pretty low at the moment, but note that I had not finished implementing all the optimization strategies I'd planned, plus that's a lot more objects on screen than will actually be required. I'm finishing up the final optimization algorithms at the moment and I expect 10-15 fps with that density, map size, and draw distance. I'll upload another video once I've completed the optimizations, maybe with a more toned down density.
29  Games Center / WIP games, tools & toy projects / Re: Ot - 3D voxel engine on: 2017-01-01 21:20:38
Thank you both. The video should be public now.
Here's another demo showing it in a much larger map
<a href="http://www.youtube.com/v/v4VnHYtDSSM?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/v4VnHYtDSSM?version=3&amp;hl=en_US&amp;start=</a>
30  Games Center / WIP games, tools & toy projects / Ot - 3D voxel engine on: 2016-12-31 19:39:51
I'll most likely be stopping working on this project as I've achieved all the goals I wanted to reach with it in terms of rendering optimizations and algorithms. Thank you to everyone for the feedback!  Smiley

Feel free to post further feedback, or ask any questions about the project.

git: https://github.com/mahhov/ot-voxel-engine

<a href="http://www.youtube.com/v/5Nw9JopHREc?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/5Nw9JopHREc?version=3&amp;hl=en_US&amp;start=</a>


<a href="http://www.youtube.com/v/Vuf5CngovKY?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/Vuf5CngovKY?version=3&amp;hl=en_US&amp;start=</a>



Note about running the code: there are 3 main methods, Engine.main will just run sandbox mode, EditorEngine.main will run just the editor mode, and Client.main will run them both (toggling back and forth via the 'm' key).

Sandbox Controls:
w, a, s, d, space, and shift - accelerate ship forward, left, backward, right, up, and down
z, x - zoom camera in and out
move mouse - change camera orientation
p - pause
enter - toggle between free-camera (controlled by mouse movement) and follow-camera (always looks towards your ship)
m - to toggle between sandbox and editor

Editor Controls:
w, a, s, d, space, and shift - to move camera
i, j, k, l, u, o - to change selected direction
1, 2, 3, 4, 0 - to change selected piece (1=hull, 2=rotor/thruster, 3=helium, 4=blade/wing, 0=delete)
mouse move - to change selected location
mouse click - to place selected piece with selected direction at selected location
enter - to reset camera to default location and orientation
\ - to load ship from file
/ - to save ship to file
m - to toggle to sandbox mode and try out your creation! (be sure to save before going to sandbox mode. sandbox mode will load from file, not from whatever is in your editor)

----------------------------------------------------------------------------------------------------------------------------------------
Original Post:


Hello,

Back in 2013, I posted of a 3d engine I had been working on but had to stop due to schoolwork. Well, this Christmas, I began a total fresh remake of the engine; this time focusing on optimizations for extremely vast terrains (rather than dense environments like my previous engine had focused on). My plans are to eventually make it support some kind of pirates battles in the sky game where you create your ships with blocks (kind of like robocraft), though I'm still considering some other ideas as well - if anyone wants to make suggestions, please go ahead Smiley

For drawing, it uses Java.Graphics2D and BufferedImage.

Here's a quick demo 1 week in.

(if anyone can help if there's an easy way to shrink the embedded image, thank you)
zip: https://www.dropbox.com/s/k0ju5zp2ijka7wl/ot.jar - outdated
git: https://github.com/mahhov/ot-voxel-engine
<a href="http://www.youtube.com/v/SDw4UxfbeQ0?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/SDw4UxfbeQ0?version=3&amp;hl=en_US&amp;start=</a>




Pages: [1] 2
 
Archive (290 views)
2017-04-27 17:45:51

buddyBro (477 views)
2017-04-05 03:38:00

CopyableCougar4 (924 views)
2017-03-24 15:39:42

theagentd (937 views)
2017-03-24 15:32:08

Rule (949 views)
2017-03-19 12:43:22

Rule (916 views)
2017-03-19 12:42:17

Rule (919 views)
2017-03-19 12:36:21

theagentd (980 views)
2017-03-16 05:07:07

theagentd (891 views)
2017-03-15 22:37:06

theagentd (688 views)
2017-03-15 22:32:18
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!