We Keep Coding

How to add octree support in JBullet

I am making a voxel-based game where large structures made of voxels can collide with each other. The game runs smoothly until two structures get to close to each other where it quickly drops to about 3 updates/second.
My current solution to adding these colliders to JBullet is by using a compound shape and using a greedy-meshing algorithm to make larger colliders out of adjacent blocks. While this is a drastic improvement over each voxel having its own collider, it still isn't fast enough to simulate large structures colliding.
I did a bunch of research and it seems that octrees are the only way to make this run in real time, but can't figure out how to add support for them in JBullet.

Java Algorithms for Geometric Primitives

I have been researching some about algorithms for geometric primitives where the two most vital for me are lines with stroke and circles. Oracle does not seem to provide the exact information for generating these shapes for painting. The reason why I want this is because I need to store the affected pixels from painting into a texturePaint[] for game collision detection. I mainly wanted expert input on if its worth even doing because just using bufferedImages is effecting how big I can make my game maps because of RAM issues. Will it slow down my painting process by a significant amount from iteration through the array or does java iterate through each pixel for painting to draw its shapes?

In terms of speed, writeableraster allows you to make pretty fast alterations to an image. You can also use tools like fork/join to speed things up faster if needed.
In terms of collision detection, I am afraid you are going to have to rely on your own hand-rolled mathematics functions. Here is an example.
EDIT:
When I was doing that kind of coding, I found that using the setPixels method in writeableraster was a LOT faster than relying on the paintComponent approach, such as drawing shapes. If you want to feel more certain, you could write some functions to test each approach by repeating the operation 10000 times and see which approach finishes faster.
Also, in addition to multithreading, you can use java's double buffering and BufferStrategy tools to prepare the subsequent rasters before they are needed. In this way, each successive raster is simply "turned on" when its turn comes because it has already been pre-rendered in the buffer.
I hope these additional links help.

jMonkey optimization similar to Java3D's

Edit: For having real-time drawing, started using lwjgl which is base of jmonkeyengine and jocl in an "interoperability" between opengl and opencl, now can calculate and draw 100k particles real-time. Maybe mantle version of jmonkey engine can cure this drawcall overhead problem.
For several days, I have been learning jMonkey engine(ver:3.0) in Eclipse(java 64 bit) and trying how to optimize a scene with using GeometryBatchFactory.optimize(rootNode); command.
Without optimization(with capability of changing spheres positions):
Okay, only 1-fps is originated from both pci-express bandwidth+jvm overhead.
With optimization(without capability to change positions of spheres):
Now it is 29 fps even with increased triangle number.
Java3D had a setCapability() method which makes a scene object be able to be read/written even in an optimized form. jMonkey engine 3.0 must be capable of this subject but I couldn't find any trace of it(searched tutorials and examples, failed).
Question: How can I set read/write position/rotation/scale capabilities of optimized nodes of a scene in jMonkey 3.0? If you cannot give an answer to first question, can you tell me why triangle numbers increase when I use optimization command? Do I have to create a new method to access the graphics card and change the variables myself(jogl maybe?)?
Scene information: 16k particles(spheres of 16x16 res) + 1 point light(and its 4096 resolutioned shadow).
I'm sure we can send several thousands of float numbers in a millisecond through pci-express with ease.
Additional info: I'm using Aparapi-kernels to update particle
positions which takes 10 milliseconds(16k * 16k interactions to
calculate forces).(does not change anything in optimized mode :( )
Can aparapi access those optimized data?
For the case of batchNode.batch(); optimization, here is 1 fps again with lessened object-numbers:
Object number is now only several hundreds but fps is still at 1!
Sending just sphere positions to gpu and letting it calculate the vertex positions could be better than calculating vertexes on cpu plus sending huge data to gpu.
No-one here to help? Already tried batchNode but did not help enough.
I dont want to change 3d api because jMonkey people already reinvented the wheel and I'm happy with current situation. Just trying to squeeze a little more performance(canceling shadows gives %100 speed but quality is important too!).
This java program will become an asteroid-impact scene simulator(there will be choice of asteroid size,mass,speed,angle) with marching-cubes algorithm with LOD(will be millions of particles).
Marching-cubes algorithm would decrease the triangle numbers greatly. If you couldnt give any answer the question, any marching-cubes(or any O(n) convex hull) algorithm for java will be accepted! Data: x,y,z arrays as source and triangle-strip-array as target(iso-surface mesh points)
Thanks.
Here are some samples about the stream(with a much lower resolution):
1)Collapsing of a cube-shaped rock-group by gravitation:
2)Exclusion force starts to show itself:
3)Exclusion force + gravitation makes the group form a more smooth shape:
4)Group forms a sphere(as expected):
5)Then, a big stellar body approaches:
6)About to touch:
7)The moment of impact:
With help of Barnes-Hutt algorithm and a truncated potential, particle numbers will be 10x(maybe 100x) more.
Rather than Marching-Cubes algorithm, a ghost cloth which wraps the nbody can give a low-resolutioned hull(more easier than BH but need more computation)
Ghost cloth will be affected by nbody(gravity + exclusion) but nbody will not be affected by cloth which wraps it. Nbody wont be rendered but cloth mesh will be rendered with lower triange count.
If MC or above works, this will let the program render a wrapping-cloth for ~200x more particles.

So sorry....
You can batch all Geometries in a scene (or a subnode) that remains static.
Batching means that all Geometries with the same Material are combined into one mesh. This optimization only has an effect if you use only few (roughly up to 32) Materials total. The pay-off is that batching takes extra time when the game is initialized
The change in triangles therefore is because they have been all assembled into one mesh.... The only suggestion if this is necessary, is trying to get the mesh and altering points on it, but at that point I don't think it makes sense.
Perhaps try a different optimization method.
Good luck, haven't used JMonkey in a bit, but glad to see others do and its continued growth!
EDIT
BTW, a way to minimize the math might be to use half a sphere of cubes, an impact on the earth likely wouldn't affect the other side (unless the sphere isn't the earth but already a small sample of the earth taken as a sphere)...
Perhaps try a 2d shape as the impact surface, though I know this won't be your best choice, it might give you an idea of how the number of shapes might have an affect and how grand. If it does then an avenue might be to consider how to remove some of the particles, if it doesn't you need not worry. I am almost sure it will.
Finally:
Perhaps don't render in real time? Take a minute to draw the frames to a buffer then play, by the time your playing you will have another 40 or so frames etc... and maybe approx 30 secs worth is all you will need.

There is a pretty solid set of documentation within the JMonkeyEngine wiki which talks quite a bit about how to utilize the transformations you are referring to, which can be found here: Advanced Spatial Concepts.
In addition, there is quite a bit of information regarding the meshes and their rendering which you can view here: Polygon Meshes.

How do I find the overlapping area between two arbitrary polygons

I'm trying to create a method that will take in two arbitrary lists of nodes, for a subject and a clipping polygon, and output either:
a) the area of the overlap
b) a list of nodes for the resulting (clipped) polygon so that I can calculate the area
I've found lots of examples which clip an arbitrary polygon using a rectangular window (which is fairly standard in graphics) but that's not what I need. I understand that it's fairly complex, particularly when you get holes, convex polygons and the like. The only simplifying assumption which I can make is that the arbitrary polygons will not contain any holes.
I'm not at all an expert in this field, so would something like the Sutherland-Hodgman algorithm work? Are there any libraries out there which already do this, or is my best bet to simply implement the algorithm as described in pseudo-code on Wikipedia?
Thanks for the help!

Are there any libraries out there which already do this ...
Polygon clipping is a complex task. I wouldn't recommend trying to do it yourself unless you want to spend many months on it.
Wikipedia lists a number of clipping libraries (and IIRC in that list only Clipper is free for use in commercial applications):
http://en.wikipedia.org/wiki/Boolean_operations_on_polygons#External_links
ps: I admit to a personal bias for Clipper since I'm the author :)
More info here: http://angusj.com/delphi/clipper.php

Sounds like Weiler-Atherton is the one you need:
The algorithm requires polygons to be
clockwise and not reentrant (self
intersecting). The algorithm can
support holes (as counter-clockwise
polygons wholly inside their parent
polygon), but requires additional
algorithms to decide which polygons
are holes.
Your polygons fit those criteria, right?
I don't know about implementations, but it sounds like you would be better off implementing W-A than S-H if either of your polygons could be concave.

Try gpc.

I found that using the JavaGeom library worked very well. It integrates the code from the Java port of GPC (which is no longer available) and thus allows arbitrary polygon operations. Using SimplePolygon2D and Polygon2DUtils.intersection() I was able to get the desired operation.

I've tried a lot of different libraries and the one that worked best was the JTS Topological Suite which is pure Java and LGPL2 licensed.

Fast graphing library

I've been using Incanter for my graphing needs, which was adequate but slow for my previous needs.
Now I need to embed a graph in a JPanel. Users will need to interact with the graph (e.g. clicking on certain points which the program would need to receive and deal with) by dragging and clicking. Zooming in a out is a must as well.
I've heard about JFreeChart on other SO discussions, but I see that Incanter uses that as it's graphing engine, and it seemed somewhat slow then. It it actually fast, but perhaps Incanter is doing things that slow it down?
I'm graphing up to 2 million points (simple xy-plots, really), though generally will be graphing less. Using Matlab, this is plotted in a few seconds, but Incanter can hang for minutes.
So is JFreeChart the way to go? Or something else, given my needs?
(Also, it needs to be free, as it is for research.)

Unfortunately, general purpose graphing solutions probably aren't going to scale well to 2 million points - that's big enough that you will need something specialized if you want interactive performance.
I can see a few sensible options:
Write your own custom "plotter" function that is optimized for drawing large numbers of points. You'd have to test it, but I think you might just about get the performance you want by writing the points directly to a BufferedImage using setRGB in a tight loop. If that still isn't fast enough, you can write the points directly into a byte array and construct a MemoryImageSource.
Exclude points so that you are only drawing e.g. 10,000 points maximum. This may be perfectly acceptable as long as you only really care about the overall shape of the scatter plot rather than individual points.
Pre-render all the points into e.g. a large BufferedImage then allow users to zoom in and out / interact with this static image. You might be able to "hack" JFreeChart to do this.
If OpenGL is an option (will require native code + getting up a steep learning curve!), then drop all the points in a big vertex array and get the graphics card to do it all for you. Will handle 2 million points in real-time without any difficulty.

MathGL is fast and free (GPL) plotting library. But I never test its java interface (swig based) since I'm not familiar with java :( . So, if one can help with testing then I'll be thankful.