46
I see. In that case, just move the call to col.ToArgb() out of the loop and assign the result, so that you don't have to do it thousands of times for frame.
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
Support / Re: Animation Interpolation Between Sequences
« on: November 06, 2019, 08:43:16 pm »
Yes, you could ignore the sub-sequences and just interpolate across the whole animation by using http://www.jpct.net/doc/com/threed/jpct/Object3D.html#animate(float). You could interpolate the needed index from the animation's total number of frames and the number of frames in each sub-sequence. However, this works only for adjacent sub-sequences and in most cases, it might look very strange anyway.
49
Support / Re: Low performance when using uncompiled objects
« on: November 04, 2019, 02:56:11 pm »
Ok, I'll go and see if I can port the compileAll method from jPCT-AE or if there was a reason not to other than my false assumption that it isn't needed... 
50
Support / Re: Low performance when using uncompiled objects
« on: October 31, 2019, 10:16:15 pm »
If it happens only when an object comes into view for the first time that uses a mesh that has never been used on any other object before, then it might be the buffer filling for the compiled data that gets transfered to the GPU. jPCT-AE has a method to do this beforehand (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/World.html#compileAllObjects()), but desktop jPCT hasn't. I guess I didn't see it as an issue on the desktop. I think that I could add it to the desktop version at least when not using the AWTGLRenderer (you aren't using that, are you?) but I want to be sure that it's actually the issue. If it is, there should be a log message like
each time the pause happens. Is there?
Quote
Subobject of object 12/blah compiled to...
each time the pause happens. Is there?
51
Support / Re: Acessing vertex color throught GLSL
« on: October 31, 2019, 09:53:20 pm »
Try
instead. I think I read my own code wrong. gl_FrontMaterial.ambient actually contains the world's global ambient color, not the object's additional color.
Code: [Select]
gl_FrontMaterial.emissioninstead. I think I read my own code wrong. gl_FrontMaterial.ambient actually contains the world's global ambient color, not the object's additional color.
52
Support / Re: Acessing vertex color throught GLSL
« on: October 28, 2019, 01:18:22 pm »
It will affect gl_FrontMaterial.ambient
53
Support / Re: Low performance when using uncompiled objects
« on: October 21, 2019, 08:53:31 am »
From an engine perspective, there's nothing going on for uncompiled objects that could cause this IMHO. There's no caching or any other kind of one-time processing involved when rendering an uncompiled object for the first time.
54
Support / Re: Low performance when using uncompiled objects
« on: October 20, 2019, 03:20:01 pm »
I would be hard pressed to say that I really see the mentioned effect in these tests...Here are the graphs as they look when running the tests on my machine from Eclipse with -Xmx and -Xms both set to 1024m in the test's runtime configuration:
Compiled:
(I guess it's too fast so the graph is out of scale, but as we don't have a problem with compiled objects, I don't mind it)
an uncompiled:
What am I looking for here? The lower framerate at the beginning? That would be caused by the JIT compiler warming up, because it gets smaller when you start the test with -server -Xcompile. Anyway, when looking at the rendered output, I can't even notice this phase, so I'm not sure if that's what we are talking about?
How do these graphs look on your machine? Oh, and another idea, just in case it's somehow caused by the graphics driver: Try Config.glVertexArrays=false before setting up your actual scene. Maybe that changes something....
Compiled:
(I guess it's too fast so the graph is out of scale, but as we don't have a problem with compiled objects, I don't mind it)
an uncompiled:
What am I looking for here? The lower framerate at the beginning? That would be caused by the JIT compiler warming up, because it gets smaller when you start the test with -server -Xcompile. Anyway, when looking at the rendered output, I can't even notice this phase, so I'm not sure if that's what we are talking about?
How do these graphs look on your machine? Oh, and another idea, just in case it's somehow caused by the graphics driver: Try Config.glVertexArrays=false before setting up your actual scene. Maybe that changes something....
55
Support / Re: Low performance when using uncompiled objects
« on: October 16, 2019, 01:35:20 pm »
Yes, just some simple example that compiles and shows the issue.
56
Support / Re: Little help with GLSL shaders
« on: October 16, 2019, 12:34:36 pm »
How can prioritize lights by using http://www.jpct.net/doc/com/threed/jpct/util/Light.html#setDistanceOverride(float)...maybe that helps?
57
Support / Re: Low performance when using uncompiled objects
« on: October 16, 2019, 12:32:06 pm »
Actually, the uncompiled pipeline renders individual polygons by pushing them to the GPU triangle after triangle. That's slow in itself, but I don't see why this should cause such a performance drop.
Can you provide me with a simple test case that shows this problem?
Can you provide me with a simple test case that shows this problem?
58
Support / Re: Extremely Newb Question.. please forgive me
« on: October 14, 2019, 12:57:17 pm »
Hex grid means an isometric view?
59
Support / Re: Little help with GLSL shaders
« on: October 14, 2019, 12:56:24 pm »
I see. Yes, that's because for uncompiled objects, the light calculation is done in software, which is limitless. But for compiled ones, it happens in the pipeline, which is limited to 8. However, it will use the 8 nearest lights per objects for that. Isn't that sufficient in your case?
60
Support / Re: Low performance when using uncompiled objects
« on: October 14, 2019, 12:54:45 pm »
You can try to do these at startup- Maybe that helps:
http://www.jpct.net/doc/com/threed/jpct/TextureManager.html#preWarm(com.threed.jpct.FrameBuffer)
http://www.jpct.net/doc/com/threed/jpct/World.html#buildAllObjects()
But actually, compiled objects are more likely to cause initial hickups...which puzzles me a bit here...
http://www.jpct.net/doc/com/threed/jpct/TextureManager.html#preWarm(com.threed.jpct.FrameBuffer)
http://www.jpct.net/doc/com/threed/jpct/World.html#buildAllObjects()
But actually, compiled objects are more likely to cause initial hickups...which puzzles me a bit here...