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 - EgonOlsen

Pages: [1] 2 3 ... 807
Support / Re: Increase number of texture units
« on: August 02, 2020, 03:41:55 pm »
I briefly looked into it. Most of the code is prepared to deal with more texture units already (or at least it looks to be; I've never actually tried it). There are few parts that have a hardcoded "4" but these are easy to change. I'll write myself a test case and see what happens if I bump it up to 8 (at least) when I find the time to do so. I guess I have to modify some parts, because the hard limit given by the constant in TextureInfo is a bad idea anyway, but if I remove it, I might have problems with memory usage. We'll see...

Support / Re: Increase number of texture units
« on: August 01, 2020, 06:10:42 pm »
No idea what that error should be. Something isn't quite right with the gl state for some reason. I would ignore it for now.

And yes, 4 is a hard coded limit. I looked into expanding it once, but decided against it for reasons that I can't remember anymore. Must have been a technical limitation of some kind. There's no way to hack around it, I'm afraid.

Bones / Re: Moved to GitHub
« on: July 21, 2020, 05:32:46 pm »
Will do when I'm back from holiday. If I don't, please remind me again... ;)

Shaders are certainly the fastest, but in a lot of cases, Animation should be good enough. Personally, I never did complex animations using a shader. I only used them for simple stuff like foliage moving in the wind. The IVertexController should be similar to Animations but the code tweaking the vertices is less efficient than the animation code in most cases, because it has a slightly higher level of abstraction.

BTW: A screen shot might help to get an idea of what the actual problem looks like...

Actually, the setting of the texture should be done automatically, if you swap the order like so:

Code: [Select]
  String texFile = "root/map.jpg";

Texture texture = new Texture(BitmapHelper.rescale(


TextureManager.getInstance().addTexture("map.jpg", texture);

Object3D modelObj = Loader.loadSerializedObject(objInputStream);

and omit the setTexture call. The loader should handle this (the log output should indicate if that had worked or not). I'm not sure if that solves the problem, though. Have you checked that loading the object directly into Android produces the correct texturing? Maybe it's a format issue...

Support / Re: relationship between Object3D and Light
« on: June 05, 2020, 08:11:11 am »
i thought of a method that saves memory and make program code more clean: sharing list between objects(or lights).
often several objects (or lights) have the same setting, they only need one list.
a good way in practice is like this: user creates a list, then set the list to several objects.
That wouldn't really work, because Light is (for historical and performance reasons) just a wrapper around an int value. When adding a Light to the Object3D, what you actually do is adding an int to an internal list. So a shared list of Light instances would have to be converted to individual int lists per object anyway, which eliminates the saving alltogether. Maybe something like

Code: [Select]
would work better? That way, I could just copy the internal int list behind the scenes with the same effect.

Support / Re: relationship between Object3D and Light
« on: June 05, 2020, 08:07:34 am »
thanks Egon, it works.
please also add object list for Light.
the logic is this, if a light has list and the object is not in list , the light is off for this object.

this test is needed only if object has null list.
if object1 has light1 in list and light1 has object2 in list, light1 in fact can lit object1 and 2.
or you may have other way to cross check these 2 types of list.
Actually, I don't really like this idea. I think that one entity should be the defining one, in this case, it's Object3D. Putting the invers logic into another class causes nothing but confusion IMHO.

please use null list if list is empty, because null doesn't refer to additional memory space.
The list is null unless you add something to it.

Support / Re: relationship between Object3D and Light
« on: June 04, 2020, 10:13:07 am »
Ok, I did something:

It adds three new methods to Object3D, namely

Code: [Select]
 * Adds a light to the list of lights specific to this object.
 * If this list is empty, all world lights be taken into account
 * when rendering the object. If there are some lights in this list,
 * ONLY these lights will be used to light the object.
 * The lights still have to added to the object's World instance
 * regardless of being in this light list or not.
 * @param light the light to add
public void addSpecificLight(Light light)

public void removeSpecificLight(Light light)

public void clearSpecificLights()

This should do what you want it to. I briefly tested it in desktop jPCT and it seemed to work as expected. Please let me know if it helps/works/fails...

Support / Re: relationship between Object3D and Light
« on: June 04, 2020, 09:24:21 am »
That should be doable. I'll look into it.

I'm not sure if I got the question correctly, but the basic idea with all loaders (that includes loading of serialized objects) is, that you assign a texture with the matching name to the TextureManager before loading, so that the loader can pick it and assign it in the loading process. If there is no such texture in the manager at load time, a dummy texture with that name will be created and you can swap it out after the loading is done. Or, if the object in question uses only one texture anyway, you should be able to set the new texture with setTexture(). Which of these ways are you using and what exactly doesn't work? Can you post some example code?

Support / Re: relationship between Object3D and Light
« on: June 04, 2020, 07:52:57 am »
I don't think jPCT-AE allows the shader variables of the default shader to be manually altered. But I believe this would maybe be one of the easier changes for jPCT that would allow for light manipulation since I suppose the default shader is based on a GLSLShader already anyway. E.g. setting diffuseColor to black or something when it's off. Though, I guess you wouldn't be sure which of the 8 lights is the 'reflection light' if the sorting of the lights array is distance based or based on in which order it got added to the world. But I believe it's something you could calculate then. I guess this solution would need 'getters' though in the GLSLShader class and access to the default shader.
You would have to duplicate one of the default shaders and modify it. I did something like this in my game Naroth to make sure that the player's light is always on. I could look it up, if needed..

Support / Re: relationship between Object3D and Light
« on: June 04, 2020, 07:51:04 am »

when the engine select Lights for object3d, (hence there is setDistanceOverride method) can you do this ? -
Code: [Select]
if (there is light list) test lights in list;
else test all lights in World;
Code: [Select]
if (this light has object list) { if (object is in list) light on; else light off }
No, not really. Because these lights still have to be part of the World or otherwise, they won't be processed properly. But if they are part of the World, they will have an influence on all other objects as well. They would limit the lights for one object but not for all the others, which is actually what you want. You could of course use this to add a light list to ALL objects managing them all by yourself, but wouldn't that be a bit tedious?

News / Forum upgraded to 2.0.17
« on: June 03, 2020, 03:24:34 pm »
See subject.

Support / Re: relationship between Object3D and Light
« on: June 03, 2020, 03:15:34 pm »
for example, a scene is divided into rooms, a light in a room should not affect objects in another room, even if the light is near to the other room. with Object3D list for Light, this scene can be setup easier.
The things is, it's not designed that way. The idea was to have a world filled with lights, just like the real world, and objects moving around which will in turn be affected by the closest light sources. Lights per object were never planned. However, I see your point. I'm just not sure how to handle this. I can't add a list of lights to Object3D, because that would break too many things in the lighting code. The "best hack" that I can come up with ATM is to extend the IRenderHook-interface (or create a LightingHook interface) that allows you to suppress some world lights for an Object3D. That's not that great either, but it would fit the engine's render pipeline...I guess...I have to think about this some more...

Pages: [1] 2 3 ... 807