61
Support / Re: ShadowHelper and special Textures
« on: December 07, 2021, 10:43:46 am »
Yes, the shadow is an additional texture as mentioned above. I wasn't aware that you are adding 2 layers yourself, so that explains it.
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.
Is these two later methods overwriting the shadow map? What is going on here?
TextureInfo ti = new TextureInfo(tid, u0, v0, u1, v1, u2, v2);
TextureInfo ti = new TextureInfo(tid, v0.x / dx, v0.z / dz, v1.x / dx, v1.z / dz, v2.x / dx, v2.z / dz);
I thought the renderhook solution should have worked as well, but apparently not..?It should have. Especially in combination with the sort offset, but I guess something interfered with the sorting in some way so that the overlay didn't render at the end, as I though it would. That might happen, the sorting is just a heuristic anyway.
public void setDepth(float depth) {
if (depth < Config.nearPlane) {
depth = Config.nearPlane + 1f;
}
this.depth = depth;
}
public void setDepth(float depth) {
if (depth < Config.nearPlane) {
depth = Config.nearPlane + 1f;
}
this.depth = depth;
}
I tried this but it didn't seem to make a difference unfortunately... Any other suggestions?
I believe Overlay#setDepth(-9E30f) sort of works best for now but still not perfectly
About the enabling/disabling, did you mean Object3D#setVisibility(boolean), World.removeObject(Object3D) or something else? (I assume these are basically the same anyway...)Depends on your implementation, I guess. Yes, jPCT takes cares of objects that aren't visible, but it's still faster to disable them in the first place if you are sure that they aren't visible in the current scene. For that, setVisibility() is usually the better option than adding/removing them. In Naroth, it's a bit different. The maps are stored as simple ASCII maps. At load time, I parse the maps and convert the ASCII data into matching beans that contain information about their position, orientation and apperance (a wall, a door, a chest...). When the player moves, I iterate through these objects to see, which ones are potentially visible (the check is rather rough, but good enough). For all that are visible, I assign an actual Object3D to them that gets positioned in the world so that it matches the data in the bean. So basically, I have a pool of Object3D instances which dynamically form the scene. If visualized, this would look like a scene out of a sci-fi movie where the world builds itself as you walk along while it collapses behind you.
Does this need to be actively done for every frame (or camera update)? I thought jPCT took care of this automatically based on what's visible inside the camera's view...
Since I assume you don't want to do the second option... Here's what I'd suggest still:There is one, just not in the way in which you expect it to be. What you have to do is to grab the information you need from the various methods in the PolygonManager, create a TextureInfo-Instance from these and assign it to the polygon by using setPolygonTexture(). This code from the wiki has an example of that in the setTexture()-method where I'm tiling a terrain texture: https://www.jpct.net/wiki/index.php?title=Texture_splatting_on_a_terrain
I think you should be able to retrieve UV coordinates from an Object3D: https://www.jpct.net/jpct-ae/doc/com/threed/jpct/PolygonManager.html#getTextureUV-int-int-
I am missing a setTextureUV() method here though...
In the end, I believe https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Object3D.html#setTextureMatrix-com.threed.jpct.Matrix- might be your best bet for scaling/offsetting UV coordinatesThat should work as well, I think...
If I remember correctly, I got black textures on some devices when using either non-square (but still POT) or NPOT textures. I believe the only way I could force to make it work was to first convert it/stretch it to a POT square texture... But yeah, memory... So I believe I didn't try to bother to go into it that much anymoreYes, that's an issue indeed. It's a driver/hardware limitation, not jPCT-AE's fault. It shouldn't be a problem on any modern hardware though.
I don't think shaders would mind additionalColor to be negative valuedThat depends on the graphics chip. Some don't mind and just clip the values below 0 and larger than 1, some render everything dark and some so crazy. One could do the clipping in the shader and/or in the code (for the fixed function pipeline, which still exists) but that would decrease performance (albeit it shouldn't be that much of an issue). But it would break compatibility with desktop jPCT, because on that one, RGBColor extends AWTColor (I don't know the reason anymore, but I'm sure that there was one... ) and that doesn't support it.