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 4 ... 807
16
Support / Re: relationship between Object3D and Light
« on: June 03, 2020, 03:00:20 pm »
I don't think the IRenderHook idea will work. The render hook gets triggered too late in the process, IIRC. At that stage, the lights have already been calculated.

17
Support / Re: relationship between Object3D and Light
« on: June 02, 2020, 06:46:17 pm »
You can disable all light sources in an object with setLighting(...). But that's not sufficient in this case, I guess?

18
I'm glad it worked!

19
Looks reasonable at first glance.  However, I'm not sure about the cube being a child of the sphere. This will apply the sphere's rotation to the cube as well, so assuming that you have rotated the sphere 90 degrees around Y (for example...) and are placing a cube at the position on the sphere that is now facing towards you, making the cube a child of the sphere will apply the same rotation to it, making it rotate the same 90 degrees, which will make him appear on the side in the end...or wouldn't it?

I'm not sure how to handle it. I guess (if that's the actual problem and I'm not totally off here) you could calculate the cube's translation like you do now, get the world transformation matrix of the sphere, invert it, matmul the result with the calculated point and translate the cube by that instead...maybe...

20
Projects / Re: my project - Vehicle Simulation
« on: May 11, 2020, 08:45:23 am »
Looking good!

21
Support / Re: Minor blitshader bug
« on: April 23, 2020, 07:48:22 pm »
Ok...it remains a mystery to me. All I've added is setting a flag that reenables some vertex buffers that shouldn't have been disabled in the first place. Well...as long as it works now.

22
Support / Re: Minor blitshader bug
« on: April 23, 2020, 06:14:46 pm »
Ok, I've updated https://jpct.de/download/beta/jpct_ae.jar. If that still doesn't have the same effect as display(), then I can do one more thing to it. Please let me know how it works out.

23
Support / Re: Minor blitshader bug
« on: April 23, 2020, 06:02:32 pm »
Opps, yes...I forgot the link. But you found it anyway... ;)

You can call display() multiple times per frame, but it will increase the internal frame counter (not a big deal though) and it's mainly done for rendering into textures. But I still don't see why this helps while flushBlittingPipeline doesn't. They aren't that different. I'll move over some additional stuff from display() into flush... for you to try out. I'll report back with a link.

24
Support / Re: a suggestion for the future of JPCT-AE
« on: April 23, 2020, 09:36:20 am »
A showcase usually depends more on art skills than it does on technical skills and I'm not very good at art, so it proves to be difficult. The wiki covers some advanced topics, but they don't look too impressive in the end either.

jPCT(-AE) was designed to be simple to use. For that, I made some sacrifices concerning flexibility. There's a lot of stuff going on in the background (even more in desktop jPCT) to hide the GL related stuff. Then people demanded for more control, so I added some things that I could add without confusing people with it who don't want to use it. It's a balancing act. If you do too little, people can't do what they want to do. But if you go too far, you'll end up with something that's actually more complex than the "clean" solution would have been in the first place, because you have to hack your way into the innards of the engine to do it. You can see this in a lot of software projects. Often when something started out to be "simple", people added stuff on top of it so that it finally lost its simplicity and ended up as an abomination of the former idea (*cough* PHP *cough* Javascript *cough*).

That said, you already have some options (as mentioned). You can set an external texture ID, but it requires you to handle GL context changes yourself. You can use the IRenderHook to inject GL calls directly into the render pipeline (you just have to make sure to restore the proper state after you are done) and you can use shaders to do all kinds of things. For that, you can provide additional vertex attributes (in Mesh) to support even more fancy shader stuff. You can't do everything with all this, but quite a lot.

25
Support / Re: Minor blitshader bug
« on: April 23, 2020, 09:21:46 am »
I'm not sure about this. Actually, I don't even understand my comment from back then anymore. Because, if you set a new blitting shader, buffered blits are executed anyway. I don't see why you should still need this dummy texture hack. fb.display() executes stored blits as well, but it also does something more. It shouldn't really hurt to use it, but I fail to see why it helps in this case. I've uploaded a new jar that adds a new method to FrameBuffer called flushBlittingPipeline() which does what it says. Maybe you can try to use that in addition or in replacement of the dummy texture blit and see if that helps.

As MichealJPCT suggested, flush() or sync() might be worth a try. There's an undocumented config switch to enable those for blitting. Set Config.blittingMode  to 9 for a flush(), to 10 for a sync() and to 11 for both and see, if that helps. I doubt it, but there has to be a reason why I put those in there...

Edit: looking at the code, these config values only enable sync() and flush() BEFORE the actual blitting. If you want to execute them afterwards as well, just add a 4 to these values.

26
Support / Re: is point sprite supported?
« on: April 23, 2020, 08:57:27 am »
It doesn't make much sense to use an Object3D for a particle system. I tried that, it didn't really work out as good as I hoped. It's better to use a single, billboarded object per particle. That's not highly efficient, but as long as you don't want to use particles extensively, it should be fine. At least that's what I'm doing and once I had it working, I never spent a second thought about it, because it was just fine IMHO.

27
Support / Re: is point sprite supported?
« on: April 22, 2020, 09:08:09 am »
I've no plans to support this. It would require a whole new data structure to support points instead of polygonal objects.

28
Support / Re: a suggestion for the future of JPCT-AE
« on: April 22, 2020, 09:05:27 am »
Deferred rendering will not work IMHO. It's too different. But apart from that, I'm not sure what exactly you are missing in terms of options to interface with GL directly? You have shaders, in which you can do everything you like, you have the IRenderHook, which you could use to inject your own calls directly into the render pipeline if you so desire and you have the option to use an externally generated texture ID for any texture.

I added these options for people who want more direct control. On the other hand, you are on your own from there on and have to make sure to not screw things up while doing your stuff. jPCT does quite a lot of (GL-)state management to keep things smooth. If you interfere with this internal state, things might get messy. But as long as you clean up after yourself, you should be good to go. So what exactly is missing?

29
Support / Re: [Tips] Huge texture uploading (memory tricks)
« on: April 07, 2020, 10:20:38 am »
BTW: Do you mind if I add this to the wiki?

30
Support / Re: [Tips] Huge texture uploading (memory tricks)
« on: April 07, 2020, 10:18:57 am »
Thanks for the contribution. setExternalId() was actually meant to be used in such edge cases. You are right about the memory consumption. It's almost doubled for a normal configuration. You can work against this by using either the Virtualizer (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Virtualizer.html) or by setting keepPixelData on a Texture to false. Both methods will still peak out at double the memory usage at reload time.

There are several reasons for keeping the pixels. One is, that the upload has to happen again on a context change. Context changes happen far less now than on older Android versions but they still might. In case they do, you have to make sure to upload your texture again yourself or you'll get garbage (or all white). Another reason is that I need the pixel data to calculate the mipmaps myself for some devices. On some older ones, the mipmap calculation is simply broken and doesn't work at all. And the last one is, that the texture isn't aware of the GL rendering context or thread. It's a simple container and it can be created in any thread you like. So you somehow have to buffer the data until the upload is feasible.

Pages: 1 [2] 3 4 ... 807