www.jpct.net
jPCT - a 3d engine for Java => Projects => Topic started by: aZen on November 11, 2013, 06:01:18 pm
-
This project relies on JPCT on a large scale and I'm very grateful for it!
>> VoxelShop (http://blackflux.com/node/11) - a voxel editor with animation support
(http://blackflux.com/software/vs/other/voxelshop-small.jpg) (http://blackflux.com/software/vs/other/voxelshop.jpg)
This currently uses the software renderer and I'm still planning to change that.
Please consider using the Blackflux forum (http://blackflux.com/forums/) if you want to give feedback. I will probably not be able to check this thread regularly in the future.
Regards,
flux
-
Looks cool. I think the software renderer is actually a good solution for this...less hassle, works everywhere, no hardware dependencies and no fighting between OpenGL and the GUI over world domination.
Edit: And if it's too slow, there always the option to enable multi-threading for it: http://www.jpct.net/wiki/index.php/Multithreading#The_software_renderer_on_multiple_cores (http://www.jpct.net/wiki/index.php/Multithreading#The_software_renderer_on_multiple_cores)
-
Thank you for the reply!
The software renderer is already multi-threaded. The problem is that the refresh rate goes down significantly when one expands the viewport (e.g. 2560x1440). I think the drawing onto the canvas is just taking too long.
Is there a way to improve that?
-
How are you doing that drawing into the canvas?
-
In reality it's more complicated, but the basic idea is:
World world = ...;
FrameBuffer buffer = ...;
buffer.clear(BGCOLOR);
world.renderScene(buffer);
world.draw(buffer);
buffer.update();
Graphics2D igr = (Graphics2D) buffer.getGraphics();
[...] (draw on the igr)
Graphics2D gr = (Graphics2D) BufferedImage.getGraphics();
buffer.display(gr);
I already did some profiling and most time is spend on draw(...) and update(), but not sure what exactly happens when the canvas enlarges, so I'll need to test that again.
-
In case that you haven't done this already, you can try to set
http://www.jpct.net/doc/com/threed/jpct/Config.html#useMultiThreadedBlitting
(http://www.jpct.net/doc/com/threed/jpct/Config.html#useMultiThreadedBlitting)
to true. It might help, it might not. It highly depends on the system.
-
In case that you haven't done this already, you can try to set
http://www.jpct.net/doc/com/threed/jpct/Config.html#useMultiThreadedBlitting
(http://www.jpct.net/doc/com/threed/jpct/Config.html#useMultiThreadedBlitting)
to true. It might help, it might not. It highly depends on the system.
Ah, yeah I had experimented with that setting in the past, but didn't really see any benefit. Will try again and report back. It sounds like it's exactly what I need.
Edit: I think it might have caused some issues, but it's definitely smoother. I've enabled it for now and will see what people report.
-
Do you have an additional screen shot? I would like to add it to the projects page, but i need two screen shots for that.
-
Sure, will get back to you in a few days when I have access to my laptop again. Is there a limit to the amount of screenshots?
-
I'm using two for each project and they will be rather small. So if you care about these things, make sure that they will look good in 240*y.
-
I'm using two for each project and they will be rather small. So if you care about these things, make sure that they will look good in 240*y.
Ok, great. I'll get back to you!
-
Made two new screenshots (click to enlarge):
(http://blackflux.com/software/vs/other/char-small.jpg) (http://blackflux.com/software/vs/other/char.jpg)
(http://blackflux.com/software/vs/other/tree-small.jpg) (http://blackflux.com/software/vs/other/tree.jpg)
And here the 240*y versions:
(http://blackflux.com/software/vs/other/char-tiny.jpg)
(http://blackflux.com/software/vs/other/tree-tiny.jpg)
-
Before I start implementing complicated optimization techniques (I have some cool stuff coming up!), I'd like to ask a few questions.
The following shows profiling done for the same scene rendered with a small frame buffer (200 x 200) and a large frame buffer (2000 x 1000). About the same amount of triangles are visible for both renders. The first number shows the absolute time spend, the second number indicates how often this code snipped was executed, etc.
buffer.clear([COLOR]); : 1425 / 564 = 2
buffer.display(gr); : 1283 / 564 = 2
drawLinkedOverlay((Graphics2D) buffer.getGraphics()); : 1281 / 564 = 2
buffer.update(); : 1300 / 564 = 2
world.draw(buffer); : 4396 / 564 = 7
world.renderScene(buffer); : 5895 / 564 = 10
buffer.display(gr); : 1928 / 565 = 3
drawLinkedOverlay((Graphics2D) buffer.getGraphics()); : 2830 / 565 = 5
buffer.update(); : 6940 / 565 = 12
buffer.clear([COLOR]); : 8080 / 565 = 14
world.draw(buffer); : 13954 / 565 = 24
world.renderScene(buffer); : 18313 / 565 = 32
Interestingly the Framebuffer.clear(Color) method "blows up". I was thinking that is must be possible to buffer the content and restore it much faster (e.g. with a low level memcpy). Is this something that you could help me with? Since this is independent of the amount of triangles in the scene (tested that), it's something I'd like to look at first.
Which times do you think will go down (and by how much) if I reduce the overall triangle count (while keeping the exact same rendering area), i.e. low poly model version?
-
I tried a lot of things to get these operations faster (including native operation via System.arraycopy) and the current solution is the best that i could come up with. The current implementation will use multiple threads if Config.useMultipleThreads is true. Are you using that? If no, it might be worth a try. If yes, it might be worth a try to disable it before clearing and enable it again afterwards.
If you reduce the polygon count, draw might improve as well as renderScene. But with the software renderer, you are usually fill rate bound in almost any case.
Edit: Thanks for the screen shots. I'll add the project, when i find the time.
-
I tried a lot of things to get these operations faster (including native operation via System.arraycopy) and the current solution is the best that i could come up with. The current implementation will use multiple threads if Config.useMultipleThreads is true. Are you using that? If no, it might be worth a try. If yes, it might be worth a try to disable it before clearing and enable it again afterwards.
I was already using multiple threads. Disabling it for the clearing increases the time from 14 to 20 ms. So that's not helping. Guess I will have to accept it. Could you explain what is happening when clearing? As I understand it, it's "just" deleting all the old data and (re)initializing the data structure. Why is that taking such a long time (I'm just curious)?
If you reduce the polygon count, draw might improve as well as renderScene. But with the software renderer, you are usually fill rate bound in almost any case.
Is there a way to determine what the bottle neck is? Considering that the optimization I have in mind is far from trivial I'd be nice to know if it's worth it. If you can think of an easy way to add profiling, that would be very much appreciated!
Edit: Thanks for the screen shots. I'll add the project, when i find the time.
Np, take your time!
-
I was already using multiple threads. Disabling it for the clearing increases the time from 14 to 20 ms. So that's not helping. Guess I will have to accept it. Could you explain what is happening when clearing? As I understand it, it's "just" deleting all the old data and (re)initializing the data structure. Why is that taking such a long time (I'm just curious)?
Actually not much. It's clearing two buffers (color and depth) and some internal data structures for HSR and things like that. However, @2000*1000, each buffer has 2,000,000 pixels which means 8,000,000 bytes. So these two buffer alone have 16mb to be cleared. That simply takes it's time...
Is there a way to determine what the bottle neck is? Considering that the optimization I have in mind is far from trivial I'd be nice to know if it's worth it. If you can think of an easy way to add profiling, that would be very much appreciated!
I would create a simple test case for this. Just render a large cube filled with small cubes and another one where you are rendering the hull only and you should get a pretty good approximation of what to expect.
-
BTW: I'll give some idea try and see if that helps...i'll report back.
Edit: Looks promising...i'll try to add my idea to the engine and see if that helps in your case.
Edit 2: No, it's not worth it. It might have been for clearing a single buffer, but accessing two of them renders it almost useless... :(
-
Which sampling mode are you actually using? Are you using oversampling?
-
Thanks for the explanation! I still think that there must be a way to allocate and initialize the memory twice and then just do a low level copy that overwrites the changed buffer memory using the second initialization. But in Java that might not be easy to do.
I've already started with the optimization I was planning to do. My test showed that it is helping in certain scenarios. Will report back when I have it working!
@Sampling: I'm using SAMPLINGMODE_OGSS. The other sampling modes were producing way too many "pixel".
This is my config initialization btw. Any suggestions for changes?
Config.fadeoutLight = false;
Config.useMultipleThreads = true;
Config.maxNumberOfCores = Runtime.getRuntime().availableProcessors();
Config.loadBalancingStrategy = 1;
Config.useMultiThreadedBlitting = true;
Config.mipmap = true;
Config.texelFilter = false;
Logger.setLogLevel(Logger.ERROR);
-
@Sampling: I'm using SAMPLINGMODE_OGSS. The other sampling modes were producing way too many "pixel".
Well, in that case, you aren't clearing 16mb but 64mb of data in each frame.
-
@Sampling: I'm using SAMPLINGMODE_OGSS. The other sampling modes were producing way too many "pixel".
Well, in that case, you aren't clearing 16mb but 64mb of data in each frame.
Yeah, that makes sense. I set it to SAMPLINGMODE_NORMAL and it's much faster, but looks very rough.
Any idea how to get the "outlines" smoother (the black outline of the voxel in the screenshot here http://blackflux.com/software/vs/other/tree.jpg )? I could live with rougher voxels, but if the outline looks pixelig that is bad. Currently I'm using setAdditionalColor and a transparent texture with a black frame. I was thinking to use the drawWireframe method instead, since that is very fast. However it draws the triangles (obviously) and not only the "outline".
Thanks for all your input so far! I really appreciate it!
-
You could try OGSS_FAST instead. It's a compromise between speed and image quality.
-
Reducing the triangle count made a huge difference. The program is now a pretty neat tech demo and, more importantly, quite fast! Work continues =)
(http://i.imgur.com/AwBhTDy.gif)
Thanks for all the support!
-
Just a quick update.
I've improved the "hull detection" and tested with large amount of voxels. At 63 ^ 3 = 250047 voxel it was getting a bit laggy. Also I think I need to adjust the heapspace (and rewrite the voxels data structure to be more memory/speed efficient). But pretty happy so far!
(http://i.imgur.com/3yYx4r6l.png)
(click to enlarge) (http://i.imgur.com/3yYx4r6.png)
Note: You can also see that the triangle count was exceeded (the selection doesn't show all triangles in the right bottom corner).
-
I've finally managed to add it to the projects page.
-
Cool, looks good!
Is there a way to create a frame buffer that allows for rendering with different sampling modes? Or do I have to create two instances (seems like it's redundant, memory wise)?
-
Created a new promo page. Certainly worth checking it out again!
Click me! (http://blackflux.com/node/11)
-
Does this application have the option to export any created models into a jPCT usable format?
-
Does this application have the option to export any created models into a jPCT usable format?
You can export to COLLADA, so yes.
Nvm, the COLLADA importer doesn't ship with jpct. So no, unfortunately atm you would need to convert the output (should be easy and fast, e.g. with blender) before you can import it to jpct.
Other formats are on my todo list though!
-
The new promo page looks nice!
-
Does this application have the option to export any created models into a jPCT usable format?
You can export to COLLADA, so yes.
Nvm, the COLLADA importer doesn't ship with jpct. So no, unfortunately atm you would need to convert the output (should be easy and fast, e.g. with blender) before you can import it to jpct.
Other formats are on my todo list though!
Very nice. I'll be following development! Also, using the bones api would work for collada :)
-
Quick Update: I've added a cool help system, so it might be time to check out the program again =)
(http://i.imgur.com/XQdB2Z9l.png) (http://i.imgur.com/XQdB2Z9.png)
-
IMPORTANT UPDATE:
VoxelShop is now open source! Always looking for contributors and feedback! If you have any issues or suggestions please post them here: https://github.com/simlu/voxelshop/issues
I'm not monitoring this thread regularly. Github is your best bet if you want a timely response!