46
Support / Re: Polyline
« on: December 09, 2013, 11:48:28 pm »
Thanks. I think I was blind there (time to stop working...).
News:
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
47
I'm trying to add a Polyline to the world. However it is never rendered. Does it not work with the software renderer? Or am I missing something obvious?
...is the code that I'm using.
Thank you!
Code: [Select]
Polyline polyline = new Polyline(triangle, Color.BLACK);
polyline.setWidth(2f);
addPolyline(polyline);...is the code that I'm using.
Thank you!
48
Support / Re: Texture Interpolation Request
« on: December 09, 2013, 09:54:21 pm »
A bit off topic, but I didn't feel like opening yet another thread (it's related at least):
I read somewhere that there might be hitching with opengl when a texture is shown for the first time. However I'm experiencing that with the software renderer: When the triangles that display a new texture are rotated into view (i.e. they are no longer culled), there is a small hitch.
How would I go about improving on that?
I read somewhere that there might be hitching with opengl when a texture is shown for the first time. However I'm experiencing that with the software renderer: When the triangles that display a new texture are rotated into view (i.e. they are no longer culled), there is a small hitch.
How would I go about improving on that?
49
Support / Re: Texture Interpolation Request
« on: December 09, 2013, 06:45:47 pm »Another "problem" might occur when using an ITextureEffect. Note that the array is a little bit larger than the actual texture. If that causes the problem, just fill the last row with the former one and you should be fine.
That worked! There was no black pixel in the image that I was loading and I couldn't for the live of it not figure out what was going on. Thank you very much!
Now I'm curious. Why is the array a bit bigger?
50
Support / Texture Interpolation Request
« on: December 09, 2013, 02:58:58 pm »
So when you use a texture and the uv position is right on the edge (when at least one position is zero or one), the outside of the texture is interpolated with black. That results in black pixels "on the edge" which looks awful. I was wondering if you could make an option so that the border color of the texture is used for interpolation (instead of black). E.g. the arbitrary point (-5,-7) would be interpolated with (0,0) of the texture and so on.
I'm not sure if this would be easy for you to implement, but it seems like something that should be done "on your side". Alternative I could "frame" the textures before adding them.
Please let me know!
I'm not sure if this would be easy for you to implement, but it seems like something that should be done "on your side". Alternative I could "frame" the textures before adding them.
Please let me know!
51
Support / Re: Texture Access
« on: December 09, 2013, 01:13:23 pm »That's what this was meant for: http://www.jpct.net/doc/com/threed/jpct/ITextureEffect.html
Sweet! Thank you!
52
Support / Texture Access
« on: December 09, 2013, 12:25:05 pm »
I'm dealing with a lot of textures that are changing rapidly. I'm wondering if it would be possible (or even make sense) to give access to the underlying pixel data of the texture.
Would it make sense to change the pixel data directly opposed to creating a new texture (I'm using the software renderer)? Would the change be visible if the texture is already loaded or would I need to reload it?
Goal is to have less memory allocation. I'm assuming that the underlying pixel data of the image that is used to instantiate the texture is duplicated into the texture. Is that correct or is a reference used?
Thank you!
Would it make sense to change the pixel data directly opposed to creating a new texture (I'm using the software renderer)? Would the change be visible if the texture is already loaded or would I need to reload it?
Goal is to have less memory allocation. I'm assuming that the underlying pixel data of the image that is used to instantiate the texture is duplicated into the texture. Is that correct or is a reference used?
Thank you!
53
Support / Re: Shouldn't MemoryHelper.compact() Free All My RAM?
« on: December 07, 2013, 05:24:10 pm »[...] gc whichforcessuggests to the vm to free unused memory. [...]
http://developer.android.com/reference/java/lang/System.html#gc%28%29
54
Feedback / Re: Tapatalk
« on: December 05, 2013, 10:42:32 pm »
Sweet! All working, thank you very much!
55
Projects / Re: VoxelShop - voxel editor
« on: December 05, 2013, 01:37:41 pm »@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!
57
Projects / Re: VoxelShop - voxel editor
« on: December 05, 2013, 11:55:26 am »
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?
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?
Code: [Select]
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);
58
Support / Re: Culling inner-cubes
« on: December 04, 2013, 06:51:36 pm »
So let me clarify some stuff.
First of all, I'm assuming that you're working on some kind of mine-craft style game. If that is not the case you would need to clarify. Secondly, the idea that Thomas had is actually not what I had in mind. I apparently didn't read his post carefully enough.
So here is the idea (I have implemented this and it is not super "easy", but certainly doable): You would need a class that manages the boxes, e.g. you can add and remove boxes (I'll call them voxel from here on to avoid confusion). This class can then be used to update your world (i.e. update triangles in the world) - you could use a refresh() function.
You shouldn't use cubes to render the voxels (since not all sides of a voxel might be visible), but rather determine which sides are visible and draw only these. Voxel that are "inside" have no visible side and are hence not drawn.
The tricky part is now to maintain a fast structure to keep track of the voxel that are currently in the world, which sides are visible and which triangles need to be changed. I have implemented this by updating the neighbors when adding/removing a voxel and also keeping a "toUpdate" list that indicates which voxel need updating.
The triangle reduction should then be implemented in a second stage (when what I just described is fully working). For that have a look at http://code.google.com/p/poly2tri/
Please let me know if you have any questions!
First of all, I'm assuming that you're working on some kind of mine-craft style game. If that is not the case you would need to clarify. Secondly, the idea that Thomas had is actually not what I had in mind. I apparently didn't read his post carefully enough.
So here is the idea (I have implemented this and it is not super "easy", but certainly doable): You would need a class that manages the boxes, e.g. you can add and remove boxes (I'll call them voxel from here on to avoid confusion). This class can then be used to update your world (i.e. update triangles in the world) - you could use a refresh() function.
You shouldn't use cubes to render the voxels (since not all sides of a voxel might be visible), but rather determine which sides are visible and draw only these. Voxel that are "inside" have no visible side and are hence not drawn.
The tricky part is now to maintain a fast structure to keep track of the voxel that are currently in the world, which sides are visible and which triangles need to be changed. I have implemented this by updating the neighbors when adding/removing a voxel and also keeping a "toUpdate" list that indicates which voxel need updating.
The triangle reduction should then be implemented in a second stage (when what I just described is fully working). For that have a look at http://code.google.com/p/poly2tri/
Please let me know if you have any questions!
59
Support / Re: Culling inner-cubes
« on: December 04, 2013, 01:07:36 pm »
Pretty much what I had to do with my voxel editor.
So what Thomas said is the easiest step (render only the outside "hull").
However you can improve it further by minimizing the amount of triangles that build the surface area. The only downside are hit detection and that you need to generate textures "on the fly". But it can drastically reduce the triangle count (e.g. for 21x21x21 voxel the outside hull would consist of 5292 triangles. After reduction it would only need 12 triangles!).
So what Thomas said is the easiest step (render only the outside "hull").
However you can improve it further by minimizing the amount of triangles that build the surface area. The only downside are hit detection and that you need to generate textures "on the fly". But it can drastically reduce the triangle count (e.g. for 21x21x21 voxel the outside hull would consist of 5292 triangles. After reduction it would only need 12 triangles!).
60
Projects / Re: VoxelShop - voxel editor
« on: December 04, 2013, 12:53:22 pm »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!