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.


Messages - Mr_Chaos

Pages: 1 [2] 3 4
16
Support / Re: Replacing a texture leads to (Native memory leak)
« on: February 08, 2015, 06:40:35 pm »
BTW: Log level should  be debug, not just verbose.

Tried with both, wasn't sure which was most important

17
Support / Re: Replacing a texture leads to (Native memory leak)
« on: February 08, 2015, 05:56:47 pm »
Forgot

Code: [Select]
Logger.setLogLevel(Logger.LL_VERBOSE);

But still this is what I get

Code: [Select]
updateElementsTexture
Loading Texture...from Image
Allocating 4194304 bytes of direct memory for texture: com.threed.jpct.Texture@32cb56e6
Caching 4194304 bytes of direct memory!

18
Support / Re: Replacing a texture leads to (Native memory leak)
« on: February 08, 2015, 05:27:05 pm »
But that's not the complete log or is it? It doesn't contain anything about uploading the new texture either. Both should happen during the next render pass.

This is all I get when changing the Texture

Allocating 4194304 bytes of direct memory for texture: com.threed.jpct.Texture@27174693
Creating new disposable buffer of size 4194304
Caching 4194304 bytes of direct memory!
updateElementsTexture <- My own log
Loading Texture...from Image


19
Support / Re: Replacing a texture leads to (Native memory leak)
« on: February 08, 2015, 01:38:31 pm »
I get this
Allocating 4194304 bytes of direct memory for texture: com.threed.jpct.Texture@25bbf0b7
Creating new disposable buffer of size 4194304
Caching 4194304 bytes of direct memory!

But nothing about unloading a texture

this is the code
Code: [Select]
        _textureManager.unloadTexture(_buffer, _elementsTexture);

        _elementsTexture = new Texture(_elementsImage);
        _elementsTexture.setMipmap(false);
        _elementsTexture.setGLFiltering(false);

        _textureManager.replaceTexture(ELEMENTS_TEXTURENAME, _elementsTexture);

20
Support / Re: Replacing a texture leads to (Native memory leak)
« on: February 08, 2015, 12:18:42 pm »
We are using the AWTGLRenderer, so that might explain it, but I am doing this in the rendering loop, so was hoping everything was synchronized allready.

I can see that I am leaking handles and my virtual memory skyrockets, after 1 hour of running I am using 6GB after 1,5 12GB and then the systems stops completely.

I'll try the FrameBuffer.synchronization and the Config.glVerbose.

21
Support / Replacing a texture leads to (Native memory leak)
« on: February 07, 2015, 07:51:06 pm »
So I have a texture that is sometimes replaced, but it seems to leak Native memory (Non heap).

I do the following

1) unload texture
2) New texture
3) Replace texture
4) Buffer.display

Is this wrong ?

22
Support / Re: Object3D.translate precision
« on: January 20, 2015, 08:36:03 am »
If it runs at
Isn't there something missing?  ???

Apart from that...maybe. Have you printed out the actual values that you are getting? You can always try to make the calculations on your own as doubles and only feed the result back into the SimpleVector for the translation. If accuracy is a problem, that might help. Another option is you blow up your complete scale by some factor, but depending on your scene setup, this might require some work...

My bad, think I hit enter too quickly. It turns out my problem was the precision of floats, not anything JPCT related.

I get my data from some other database, to the model is not centered around 0,0,0, but around some arbitrary point, which in this case means my object is located at 53434.4,-2.1790001,-83023.28 and I want to translate it (-0.65774244,0.0,0.7532429), which doesn't work.

By changing my models to be centered around 0,0,0 the translation works perfectly.

23
Support / Object3D.translate precision
« on: January 19, 2015, 09:18:46 pm »
I have a very strange problem.

I move some objects using based, but when the speed gets low, my calculations seem to go wrong.

I run my program at 16ms pr. tick

I have an object moving at 0.5 pr second, with a vector of (-0.65774244,0.0,0.7532429)

Code: [Select]
    _translation.set(_currentDirection);
    _translation.scalarMul((_currentSpeed * time) / 1000f);
    _object.translate(_translation);

But the tote doesn't follow the line at all, so I'm wondering if I'm hitting the edge of what a float and thereby Object3D.translate can support ?

If it runs at

24
Support / LWJGL 3.0 ?
« on: November 15, 2014, 10:23:00 pm »
It seems LWJGL 3.0 has finally been released, are you (Egon the man with the plan) planning on updating JPCT ?

25
Yes, vertices will be shared by default. You can disable it on an Object3D by calling disableVertexSharing();, but you have to create the mesh yourself then by using addTriangle or it will have no effect.
If I had only known this (AKA read the javadoc before coding  ;)

26
I use the correct compile method, but I think my problem is vertixes having multiple texture coordinates.

Let's say i want to write the letters A and Z, A has texture coordinate(u(0.00->0.1), v(0.0->0.1) and Z has (u(0.9->1.0), v(09->1.0).

Then 2 of the vertixes will have both coordinates for A and Z

My current solution (not pretty) is to double the number of squares and only use one out of two.

I'll post some code later I someone else is having the same problem and maybee some of the experts can tell me how stupid the code is :)

27
I think I found my problem and a new solution.

The problem was creating the texture(Without ITextureEffect) or modyfying the existing texture(With ITextureEffect).
Clearing the texture took 2ms and rendering the text took 4ms.

My new solution is to create one big texture with all letters and then making the Object3D plane consist of 12 squares and then change the UV coordinates of the vertixes to show the correct letters.

It takes less than 1 ms to update a plane, so the performance is there, but my problem is that if I run compile on the Object3D I think JPCT optimizes away some of the vertices and then I have a hard time using the PolygonManager to update them since they are missing (Hope this makes sense).


28
Updating a texture is expensive in terms of performance. Are you actually creating new texture instances? In that case, consider to use an ITextureEffect implementation to update an existing texture instead of creating a new one.
Or use blitting from a texture that contains all letters to create your text output. Have a look at raft's GLFont class, that does a pretty good job with that.

Yes, I am creating a new Texture everytime, I'll look into ITextureEffect, and get back with some performance numbers.

29
:-[Many small ones sound better to me in this case, because you are only updating some of the text at a time, if i got that right. Is it possible that all 32 objects are visible at once? If not, then maybe you can pool the plane objects and won't need all 32 of them.
If you don't update the textures at runtime, one large one might be better. But as AGP already said: It's unlikely that it really matters.

You're right I only update some of them, whenever the object is visible, all 32 being updated is a worst case scenario and doesn't happe very often.

Right now my problem is the hit I get when updating the texture, it brings the tablet to a crawl :/

30
I have some objects that I want to have a description on top of, my current solution is.

Make 32 transparent planes which are not visible from the start
For each plane make a texture (1024x128) for the text

  • On each drawcall, check each objects distance to the camera
  • If the distance is less than X
    • Get a plane and translate it to the correct location
    • Create a new texture with the correct String
    • Update the texture in the texture manager

My question is if this is the best way of doing it ?

My other suggestion would be to have 1 big texture instead of 32 small ones.
 






Pages: 1 [2] 3 4