Hey!

I believe the distance-based texture quality thing you're talking about could be done with mipmapping with distance-based level of detail (LOD) texture fetching.

I believe jPCT has support for mipmapping but I've found it a little buggy for myself... (Or I'm just not sure how to make use of it properly)
I'm not sure if default shaders use this...

I believe for this technique, you should take into account that twice the memory consumption of the base texture is necessary. (With a peak of 4 times the memory consumption of a single base texture with default jPCT texture loading (I'm not entirely sure about this, however)).

LOD	Resolution
Level 0 (base)	8x * 4x
Level 1	4x * 2x
Level 2	2x * 1x
Level 3	1x * 0.5x
Level 4	etc...

with x being some resolution scaling factor...

I believe if your texture loading 'algorithm' is efficiënt you could probably get away with loading textures at at a maximum peak memory consumption of just twice the base texture memory consumption.

The memory consumption of a single texture can be calculated approximately as follows:(https://www.jpct.net/wiki/index.php/Reducing_memory_usage)
Remember: 8 bits = 1 byte

Higher color quality:
For 32-bit: width * height * 4 bytes
For 24-bit: width * height * 3 bytes (no alpha)

Lower color quality:
For 16-bit: width * height * 2 bytes
For 12-bit: width * height * 1.5 bytes (no alpha)

So for example:
Let's say you have a 32-bit texture of 8192 by 4096 pixels.
The memory consumption can be calculated with the above formula.
This would result in approximately 130 MB.
When doing mipmapping, the memory consumption will be nearly doubled, so that'd be 260MB.
I believe that with jPCT's default texture loading algorithm, it'd be doubled in peak memory consumption for both scenarios.
260 MB without mipmapping, 520 MB with mipmapping.

Maybe something else that could be useful:
https://www.jpct.net/forum2/index.php/topic,5135.0.html
I guess it could be extended to allow for more efficient texture loading and also mipmapping... Mind that Android makes a distinction between loading textures to (J)VM memory and native memory, where the first is usually more limited...

Hope this was useful in some way!

Hello,

I was trying to create a glass/mirror-like object.
For this I needed to get rid of the World's ambient lighting and the Light's diffuse lighting.

I was able to get rid of the World's ambient lighting (which affected all objects in the scene unfortunately, but for those objects I used Object3D#setAdditionalColor again to mimic ambient lighting)
However, I wasn't able to change the diffuse nor specular color seperately..? Or I wouldn't know how to...
The Light class has a Light#setIntensity() method but I suppose that works on both diffuse and specular color.

According to the Wiki, the shaders do seem ready to support distinctive diffuse and specular lighting colors
(https://www.jpct.net/wiki/index.php/OpenGL_ES_2.0_support)
uniform vec3 diffuseColors[8]; - The diffuse color of each light source.
uniform vec3 specularColors[8]; - The specular color of each light source.It seemed a little odd to me that these variables are seperately declared there but they seem to always be the same arrays basically..? (If I'm not mistaken and didn't overlook something)

I believe the following three (or four) things would help me a lot:
- Allow Object3D#setAdditionalColor(r,g,b) to have negative values for r, g and b so they can cancel out the World's ambient lighting (rather than having to do it in the opposite way...)
- Add Light#setSpecularIntensity(r,g,b) to control specular lighting intensity seperately
- Add Light#setDiffuseIntensity(r,g,b) to control diffuse lighting intensity seperately
(- Perhaps extra Object3D lighting modes (ambient only, additional only, diffuse only, specular only; and different combinations of these 4).)

Thank you for your time

Cheers,
AeroShark333

Maybe you could have 0 light sources and use https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Object3D.html#setAdditionalColor-com.threed.jpct.RGBColor- to 'add' your own lighting...
But I'm not sure if this would give the desired result...
I believe the best way to work yourself around the default lighting system of jPCT is to write your own shaders which take care of the lighting themselves... Could be tricky however

I assume your model should be fine...
You probably have to tweak jPCT a little so it shows all polygons (or polygons in the far-plane) properly

I'd recommend tweaking with these options:
https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#maxPolysVisible
Config.maxPolysVisible = 2048;
https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#nearPlane
Config.nearPlane = 1E-3;
https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#farPlane
Config.farPlane = 1E9;

I believe if values are repetitively added, I suppose you should do an inverse operation at the end of what you are doing..? So maybe the inverse matrix or something would help (Matrix.invert()).

What you could also do is not apply the initial rotation at first but only at the end maybe. So after your vertex controller things..?

I'm not sure if I entirely understand your problem. It's hard to understand if you don't see what's happening

Maybe this would work:

aaa[f].matMul(cyl7.getRotationMatrix());
Then:
aaa[f].matMul(cyl7.getTranslationMatrix());

I'm not sure if this will work... I can't test this out right now, but it would somewhat make sense I hoped... 😅 Otherwise, maybe Egon has better ideas

How get global(world) coordinate of vertex from mesh?In GenerateVertexController

I guess you'd need to pass your Object3D instance to your custom implementation of GenericVertexController.
Then using Object3D.getTransfornedCenter() to find the mesh's center in world coordinates. And using the rotations applied to the Object3D and GenericVertexController.getSourceMesh() to find the individual world coordinates.
...

However, maybe multiplying the sourceMesh with object3d.getWorldTransformation() could work too... Seems to go from object space to world space..?