Flow - A Java voxel engine, using LWJGL

Engines, Libraries and Tools
#1

Flow is a Java voxel engine and platform, supporting servers and clients. It uses LWJGL, and has been in some form of development for a long time. Source code can be found at https://github.com/flow

Flow isn’t completed. Originally, there was Spout, designed to be a voxel engine / platform, but it died after most of the team became inactive. Lots of Spout code is reused in Flow, but Flow only has a few developers working on it. It’s modular - i.e pretty much everything is a library (a good few of these libraries are nearly done). The idea behind this is that if everything crashes and burns there are still usable libraries left behind.

Essentially, Flow exists to provide a high-performance platform which you can write any form of voxel game for, while doing everything in a way which means it can be modified or customised without touching the source of the engine itself. The API is pretty extensive, and isn’t limited by the requirement of clientside modifications like Minecraft is because most stuff is serverside…

Here are some basic ideas which Flow is built around:

  • The ability to create any voxel game. The idea of Spout was to create a Minecraft clone and then expand from there, but the Flow developers like Space Engineers and similar games too
  • Multithreading and efficiency - Flow is multithreaded and efficient.
  • Flexibility - Everything is a plugin - even the game you’re playing. This means plugins can change absolutely anything.

I would encourage people to get involved in Flow and contribute to it - it’s very open to the community and pull requests are invited by their team. Discussion takes place at http://spoutcraft.org at the moment (scroll to the bottom of the forums), but that’s just a temporary home until they get http://flowpowered.com sorted out.

#2

Thing is there’s nothing to picture yet.

#3

A picture is worth a thousand words. You can’t expect people to dive into your code, or to try it out without even demonstrating what it’s capable of.

#4

So you haven’t tested your engine then…? If you have, just take a picture of what you have tested! I can tell you a picture is way better than a wall of text. Hook the reader in with interesting pictures and then get them to test your engine out.

#5

I think it’s a bit too early to post here. Without any screenshots, these kinda topics wont generate user interest.

#6

It’s not my engine :stuck_out_tongue:

But yeah, I agree that pictures are worth a lot, it’s just there aren’t many of them yet.

#7

Hi

What are the advantages of this voxel engine in comparison with ArdorCraftAPI (based on Ardor3D)?

#8

Wrong. Spout wasn’t trying to clone Minecraft, instead it was a mod to allow communication with the server-side Spout plugin for Bukkit which allows the server to do stuff that normally you couldn’t do with the default client. How does voxel engines come into play then?

Also if I understand you correctly you are currently promoting an engine that you’ve never seen in action? Wow. ::slight_smile:

#9

I’ve found a nice implementation of Sweep-and-prune in this engine:
https://github.com/flow/React/blob/master/src/main/java/org/spout/physics/collision/broadphase/SweepAndPruneAlgorithm.java

#10

You don’t know what you’re talking about. Spoutcraft and SpoutPlugin are not the same as Spout. They are legacy projects which were modifications to Minecraft itself. Spout, the voxel game engine, located at https://github.com/SpoutDev/Spout is entirely different.

I wouldn’t even say I’m promoting it. I’m posting here to discuss peoples’ opinions of it. Spout ended up getting pretty far, and was very impressive - you could log in and almost all Minecraft functionality was there with the use of the Vanilla plugin, and it was much faster than Minecraft, as well as having a decent API, but there were a couple of major problems which prompted the change.

Flow is a more modern engine - an example of this is the fact that ArdorCraft uses fixed function rendering whereas Flow can support rendering with OpenGL 1, 2 or 3 depending on the user’s computer. ArdorCraft also seems to be geared entirely towards first-person block worlds (feel free to correct me here - I’ve never used it, just getting an idea from the google code page) whereas Flow can be a lot more flexible than that.

#11

Cool (the physics engine is a port of https://code.google.com/p/reactphysics3d/ if you’re interested / not aware :P)

#12

I also found some images demonstrating what Caustic (the flow renderer) and React (the flow physics engine) can do:

http://spoutcraft.org/attachments/sandbox-shadows-png.2183/

http://spoutcraft.org/attachments/screenshot-37-png.2184/

http://spoutcraft.org/attachments/adl-dropboxusercontent-com_u_43006973_motion_20blur-png.6987/

#13

Have done - thanks for the tip :slight_smile:

#14

When some methods of the fixed pipeline aren’t available, the JOGL renderer of JogAmp’s Ardor3D Continuation tries to use another code path, some features of the fixed pipeline are emulated with shaders in JOGL itself. It supports OpenGL 1.2 to 4 and OpenGL-ES 1 to 3 but it doesn’t support forward compatible profiles. Flow supports physics and networking whereas ArdorCraft don’t. What you wrote about Flow isn’t completely true, I’ve just looked at Caustic, it uses the retained mode, it doesn’t work without vertex arrays and I’m not sure it can work without shader support. Moreover, I have found an OBJ loader, it doesn’t allow to load animated objects except if you store each frame into a separate file and if you build your own key frame controller.

#15

Ah, that would make sense - as I said, I’ve never used Ardor. And yeah, Caustic now works with OpenGL 2 + 3 - I’d forgotten that they removed the OpenGL 1 support a little while back because they felt it was unnecessary.