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   
Pages: [1]
  ignore  |  Print  
  [LWJGL] Voxels - Display lists vs. Instanced Arrays  (Read 856 times)
0 Members and 1 Guest are viewing this topic.
Offline EnderNinja7

Senior Newbie


Medals: 1
Exp: 2 years


The beginning of the end


« Posted 2017-03-23 07:28:59 »

I am working on a voxel engine. When I saw all the other voxel engines here I saw that most of the projects were rendered using Display Lists (Minecraft too) . Is there a reason for this? According to AlwaysGeeky https://sites.google.com/site/letsmakeavoxelengine/home/display-lists-or-vertex-buffers :-

Quote
-Vertex buffers allow us to group up our data into a big array and then send it all to the graphics card together (each frame).
-Display lists are special lists of render calls that are stored on the GPU itself and rendered each frame when the list is rendered, but we dont have to send this data to the GPU every frame.

So which one is the best for my requirements (details are given below)

My voxel engine would have :-

Small voxels (I might have to use tessellation)

Realistic physics and lighting (Shaders are a must)

Target - PC, Consoles (hopefully)

Also if Display lists are better can you link a tutorial for that as I am used to OpenGL 3.0 above pipeline ?
Offline elect

JGO Knight


Medals: 42



« Reply #1 - Posted 2017-03-23 08:38:54 »

Display lists are deprecated, skip them
Offline Longor1996
« Reply #2 - Posted 2017-03-23 18:47:58 »

Display Lists (Minecraft too)

Minecraft does NOT use DisplayLists... it uses vertex arrays/buffers for everything for over two years by now. As elect said, they are deprecated, use vertex arrays/buffers.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd

« JGO Bitwise Duke »


Medals: 970
Projects: 4
Exp: 8 years



« Reply #3 - Posted 2017-03-23 21:58:17 »

As everyone's already said, display lists are deprecated since many years back. Vertex buffer objects is the way to go nowadays.

There's a reason why voxels are generally kept pretty big. Storing volume information requires huge amounts of memory usually. Consider a simple case where you want a 500 voxel view distance and you have a maximum height of 200 voxels. To allow the player to look around properly, you'd need to have all voxels within a 500 radius circle around the player loaded in. This is essentially a 1000x1000x200 volume of voxels, or two hundred MILLION voxels. Storing each voxel as an object will use at least 8 bytes per voxel (even an empty Java object uses 8 bytes), so you're already talking about 1000*1000*200*8 bytes, which is equal to 1.5GBs of memory right there. Let's say you want smaller voxels, so you cut each voxel into 8 smaller voxels. Well, now you have 8 times as many voxels, so that's 12GBs of memory you have now. There are a lot of tricks for reducing the memory usage of voxel worlds, and this should be your first focus (after you got basic rendering working).

Tessellation isn't really something you can use for voxel worlds effectively to get smaller voxels. Due to how most voxel world rendering techniques work, both the smallest and biggest piece of geometry you can render is a single voxel's face. The nature of voxel worlds makes it very hard to combine multiple voxels into a single surface without handling a lot of special cases, so it's an optimization that is rarely done. Tessellation allows you to dynamically divide one triangle or quad into more triangles or quads. This isn't really what you want to do in your voxel world, because it would require you to merge voxels ahead of time, then dynamically subdivide them again to get the original voxels back, which like I said is really hard to do. This means that tessellation doesn't really fill much of a function in voxel worlds. If none of what I just said makes sense to you, you should consider reading up more on tessellation and what it's actually used for nowadays, what its advantages and disadvantages are, etc.

Realistic physics can be a big challenge to do for big worlds. Again, memory usage can be a big issue, but performance is a more likely problem here as well. If you're hellbent on having physics, I'd recommend taking a look at the Bullet physics engine, as that's your best bet at achieving realistic physics. Still, it's definitely not an easy task.

Indeed, shaders are a must for the OpenGL 3 pipeline, because you literally need to have a shader program to be able to render anything at all. That is unless you use the compatibility profile, which is basically just the ability to use the older stuff that they removed from OpenGL 3 in OpenGL 3, which means... that it's not really OpenGL 3 in the first place. It sounds like you need to get some basic rendering working in the OpenGL 3 pipeline before you should start with your voxel world. Don't worry though; rendering a voxel world isn't that complicated once you actually got your first couple of triangles rendered properly.

If you want to target consoles, then Java is definitely the wrong platform for you. Although there are ways to run Java games on consoles, there's currently no known way of achieving hardware acceleration for the graphics (or OpenGL at all), so they're essentially limited to simple 2D graphics. You need to look elsewhere if you want to run your games on consoles, probably the Unity engine and Unreal engine. If you just want to run your game on phones and tablets (as well as PC), then Java is a great choice. LibGDX is the go-to library for that, but LWJGL is seeing initial support for Android right now. Exciting times!

I don't want to be negative, but you may want to take a step back and try to figure out what is actually achievable for you at your current skill level. It's good that you're trying to learn more to achieve your goals, so don't let me discourage you from continuing, but maybe consider starting with the basics and working yourself up from there at least.

Myomyomyo.
Offline EnderNinja7

Senior Newbie


Medals: 1
Exp: 2 years


The beginning of the end


« Reply #4 - Posted 2017-03-24 05:34:45 »

There's a reason why voxels are generally kept pretty big. Storing volume information requires huge amounts of memory usually. Consider a simple case where you want a 500 voxel view distance and you have a maximum height of 200 voxels. To allow the player to look around properly, you'd need to have all voxels within a 500 radius circle around the player loaded in. This is essentially a 1000x1000x200 volume of voxels, or two hundred MILLION voxels. Storing each voxel as an object will use at least 8 bytes per voxel (even an empty Java object uses 8 bytes), so you're already talking about 1000*1000*200*8 bytes, which is equal to 1.5GBs of memory right there. Let's say you want smaller voxels, so you cut each voxel into 8 smaller voxels. Well, now you have 8 times as many voxels, so that's 12GBs of memory you have now. There are a lot of tricks for reducing the memory usage of voxel worlds, and this should be your first focus (after you got basic rendering working).
Yeah, I will have to crunch some numbers.
Tessellation isn't really something you can use for voxel worlds effectively to get smaller voxels. Due to how most voxel world rendering techniques work, both the smallest and biggest piece of geometry you can render is a single voxel's face. The nature of voxel worlds makes it very hard to combine multiple voxels into a single surface without handling a lot of special cases, so it's an optimization that is rarely done. Tessellation allows you to dynamically divide one triangle or quad into more triangles or quads. This isn't really what you want to do in your voxel world, because it would require you to merge voxels ahead of time, then dynamically subdivide them again to get the original voxels back, which like I said is really hard to do. This means that tessellation doesn't really fill much of a function in voxel worlds. If none of what I just said makes sense to you, you should consider reading up more on tessellation and what it's actually used for nowadays, what its advantages and disadvantages are, etc.
Sorry, noob mistake. Too excited on new features
If you want to target consoles, then Java is definitely the wrong platform for you. Although there are ways to run Java games on consoles, there's currently no known way of achieving hardware acceleration for the graphics (or OpenGL at all), so they're essentially limited to simple 2D graphics.
Consoles - Just saying. I saw a large "Java Powered" with the logo, acknowledgements and all on my new box of PS4 last year. So I thought if there is a JVM in PS4 , why not put it to good use? And you mean Minecraft for consoles was coded in C++?
You need to look elsewhere if you want to run your games on consoles, probably the Unity engine and Unreal engine. If you just want to run your game on phones and tablets (as well as PC), then Java is a great choice. LibGDX is the go-to library for that, but LWJGL is seeing initial support for Android right now. Exciting times!
Basically, Java was NOT my first choice. It is almost one year since I formally started on working on my game, yet I have almost nothing but a few hundred lines of code and 9.5 months of failed experience . Also, I used the EXACT two engines you mentioned.

Last year, I started to work on my game. I first used Unreal Engine as some of my friends told me that it is the best game engine there is. For two months I learnt Blueprint and a little of C++ in Unreal. After that I started to work on voxel engines. Later I found out that the 'Engine in an Engine' was too much of a power hog (I am developing in a laptop). Then I moved on to Unity as I saw that there were a lot of voxel engine tuts for it.  4.3 months were spent on learning C#. I realized that the code depended on the syntax of the library, not the actual language (Unity C# was very similar to Java) . Then for two months I made two attempts to make my game.

Attempt 1 : FAILED
Attempt 2: I borrowed a bit from a voxel framework, but then I made a very complex pipeline and it was very difficult to :-
Optimize it
and add new features

Some good fellow at stack exchange told me that OpenGL is the best tool for my job. I chose Java with lwjgl as at that time I was being taught Java at school and I was very good at it.
 
So now I do not use any game engine and high level library because of this. So lwjgl for me.

Yes, I am very arrogant but sometimes arrogance helps. With luck, I might be the Steve Jobs of Java Game Development.

EDIT : I KNEW IT! Thanks everyone for supporting vao/vbos
Offline theagentd

« JGO Bitwise Duke »


Medals: 970
Projects: 4
Exp: 8 years



« Reply #5 - Posted 2017-03-24 09:15:21 »

Most likely the reason for the Java Powered logo on your PS4 is that Blu-ray menus are actually coded in Java. So yes, technically there are JVMs for most consoles and even just normal Blu-ray players, but they don't expose the raw graphics API there, only Java2D. It simply isn't suited for 3D graphics at all. See the Blu-Play thread here: http://www.java-gaming.org/index.php?topic=38044.0

Yes, Minecraft was ported to quite a few languages AFAIK. The wikipedia place specifically mentions that the pocket edition version is coded in C++. It doesn't run on Java on consoles either AFAIK.

I don't think you come off as arrogant at all. It's not arrogant to have dreams and being aware of your potential. It's arrogant to think that you're infallible, and if that gets in the way of your learning because you can't accept criticism, you're an idiot. You don't seem that way at all; you just seem like you're determined to learn, and you haven't given up yet despite your attempts not working out. Good luck!

Myomyomyo.
Pages: [1]
  ignore  |  Print  
 
 

 
Archive (284 views)
2017-04-27 17:45:51

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

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

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

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

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

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

theagentd (965 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!