www.jpct.net
General => News => Topic started by: EgonOlsen on January 24, 2007, 11:17:13 pm
-
This time, i'll start with a beta version instead of releasing a final version, because i made some changes that affect some internals and i'm not 100% sure that i got everything right in the end. So here you go:
http://www.jpct.net/download/beta/jpctapi.zip
This is the same version that i referenced to in two other threads. By posting it here, i hope to broaden the audience...
Changes so far are:
1.13 - Fixed a bug in the new Light class in the util-package. Added support for anti aliasing (2x and 4x) to the hardware renderer. Fixed a stupidity in FrameBuffer. Worked around a problem in the KeyMapper that caused an infinite loop when creating the Keyboard under some circumstances. Added a synchronization object for similar purposes to FrameBuffer. Added support for post processing of the framebuffer as well as an implementation that offers a bloom effect (kind of pseudo-hdr) for the OpenGL renderers. Added support for "render to texture" for all renderers. With this, it's possible to redirect the render into a texture instead of the actual framebuffer. Removed support for the legacy mode for OpenGL. Changed a framebuffer's default mode to software/opengl-alike instead of legacy. This is another step into the direction of dropping legacy support completly in the future. Changed RGB-Scale setting in the OpenGL renderers. Added support for Wavefront's OBJ-format to Loader. The framebuffer's alpha value is no longer 0 but 255 when using the software renderer. In addition, you can enable a framebuffer that supports alpha values for the software renderer by setting Config.useFramebufferWithAlpha to true. Fixed a bug in the per-pixel-fog of the software renderer when combined with oversampling.
-
Fantastic!
It gets better and better;)
-
Awesome, thanks a lot for your hard work, Egon. I really appreciate it, pal, as I'm sure do a lot of people.
Now for a request: GenericVertexController.getUpdatedMesh(), which would return the destination mesh with all current modifications, even if it would be slow. Sometimes I want to write my own collision-detection code, and that method would be priceless.
-
one difference i've noticed is this, colors changed for transparent objects. sun glasses in karga is an example. the sunglasses which were blue/gray was almost petroleum green now
-
:shock: Oops! Yes, you are right. I can verify this problem. I'll have a look...
-
Fixed (at least i hope so...)! The new version has been uploaded.
-
seemed fixed to me, i've also updated karga too :D
-
For all of you with a little more adventure spirit, here's a beta of the beta which reduces memory footprint for Object3Ds: http://www.jpct.net/download/beta/jpctapi2.zip
-
i've downloaded and started to use it locally. i will make you know if i encounter any anomalies ;)
r a f t
-
i've downloaded and started to use it locally. i will make you know if i encounter any anomalies ;)
This was ten days ago, so am i save to say that you haven't encountered any anomalies then? At least i haven't.
I just wanted to be sure before releasing this version as stable.
-
I am not entirely sure which version I am using :o.
I really MUST try this bloom effect! I want to "bind" a light to a torch object3D,
and see if it looks anything like fire.
Im not sure if that is one of it's uses, but I am interested in how it turns out;)
Sorry, I know this not what you asked.
-
Well, I would like to try the new features but with the mi new work and mi just born son, I have no time. Hope I can use it sooner.
-
I've had no problems with it whatsoever. Except with that method you made for me (or else it's my code, but it doesn't look like it to me). It doesn't seem to update the vertices, because the collision isn't happening on time. But, by all means, update the package with the new lwjgl and put it up.
-
Except with that method you made for me (or else it's my code, but it doesn't look like it to me). It doesn't seem to update the vertices, because the collision isn't happening on time.
Could be that it doesn't do what you expect it to do because i was never really sure what that was... ;) What it currently does, is to update the data IN the vertex controller with the data FROM the actual mesh. Is that what it's supposed to do?
-
I hate to sound clueless, but I've been assuming the vertex data is given in world space. Is that what it does? Would testing vertex for vertex whether it's inside another mesh work (however slow)? What I hoped the VertexController did was first of all to give me world-space vertices, then for the updateMeshData() method to update those vertices including any translations that may have been applied to the model. Now I'm confused. Are we on the same page? :-) Again, thanks for all your hard work, Egon.
-
It gives you everything in object space.
You would need to convert the vertex vectors into world space, and compare them
against the other model using a ray, or something like that:).
-
Cyber is right, it's all in object space. If you want it in world space, you've to transform it yourself. But most of the time, it's better to transform the collision source (i.e. what should be checked for collision with this mesh) into object space of the mesh in question by applying the inverse world transformation and transform the result back into world space. That way, you don't have to transform all of the vertices of the mesh.
-
Okay, how do I apply the inverse world transformation? And why would I then transform the result back into world space (presumably after the collision detection)?
-
The invert of a matrix is just matrix.invert(), or matrix.invert3x3() to pretend its only rotational(if i understand right:)).
-
And why would I then transform the result back into world space (presumably after the collision detection)?
To do something with it. You move into world space and so do your collision partners. But doing the detection in object space leads to a corrected movement vector in object space. You can't apply it into world space directly.