http://s13.invisionfree.com/Heroes_of_Ardania_v2/index.php?showtopic=67&st=0#entry2033965
The attachment there is a zipfile that demos the problem I’ve been having with setting TransparencyAttributes to BLENDED- the smaller square I generate appears to disappear behind the larger one, which is impossible. Using an opaque surface fixes this problem, but I definitely need to be able to present transparency. Any clues as to the problem here? Any help would be greatly appreciated.
Are you using TRANSPARENCY_SORT_GEOMETRY on the view? The default transparency sort policy is TRANSPARENCY_SORT_NONE.
Mike
Thanks for the help! Though why on Earth J3D should have it’s default set to anything else boggles my mind…
Hmm. After testing, while this solves the problem for transparency sorting between different Shape3Ds, it does nothing to help sorting within a single Shape3D. Most irritating. It’s not as if Transparency support is rarely required of typical 3D apps these days, you’d think the engine would cover it somewhere…
Most apps do not require polygons sorted by transparency. There are techincal reasons why this would be to slow. In particular if there are many polygons. I don’t know what your trying to do but try to think of a workaround where you don’t use transparency, or find a clever way of breaking the geometry up to reduce the visual artifacts.
It is possible to implement it yourself, but it’s a huge amount of work and would be dog slow.
[quote]I don’t know what your trying to do…
[/quote]
http://s13.invisionfree.com/Heroes_of_Ardania_v2/index.php?showtopic=67
If you’re really curious, theres a zipfile for a more complete demo, at the top of the thread.
Oh, it can probably be worked around with reasonable success, but I don’t think it’s fair to say most 3D apps don’t require transparency support. Warcraft3 certainly seemed capable of it, and I’m looking to rig up an engine with roughly the same properties. I already have bone-based animation support worked out, the models just display terribly unless I turn off transparency. Surely most modern games can deal with this sort of demand? It’s like in java2d, they don’t have proper hardware-accelerated transparency support worked out yet, so I had to go devise my own engine to handle it. And it was a huge amount of work, and dog slow unless I re-used most of the canvas each frame. But surely there’s a method of skipping screen regions that you know have been rendered completely opaque at less depth than the current poly, and skipping those? I applied something similar to my 2d engine and got good, (approaching O(n),) results, but then, I’m no expert at 3d.
Plus, I don’t think they’ve released the source code for the OSX implementation of J3d. So, I couldn’t really go about tweaking the code myself. And it would all get very platform-dependant.
Bah… …oh well. Thanks for the advice.
[quote]If you’re really curious, theres a zipfile for a more complete demo, at the top of the thread.
[/quote]
Sorry, but getting someones source code to compile is way to much work. In particular since I’m guessing I have to download and intall java3d and possible java5. If you had a screenshot I could look at it.
[quote]Oh, it can probably be worked around with reasonable success, but I don’t think it’s fair to say most 3D apps don’t require transparency support. Warcraft3 certainly seemed capable of it, and I’m looking to rig up an engine with roughly the same properties.
[/quote]
I did not say games don’t use transparency. But they don’t do perfect polygon sorted transparency like you suggested when you said “it does nothing to help sorting within a single Shape3D”. There are workarounds, but what is best depends on what you are rendering. Trees and grass can be rendered with on/off transparency and set up correctly can be rendered without sorting. Other times it can be enough to turn off depth write. That will help with the “hidden by transparent triangle” bug, but can lead to “triangles not sorted bug” material is more opaque than transparent. In any case, the Warcraft 3 people knows all this and the levels is buildt so that the bugs don’t stand out.
[quote] But surely there’s a method of skipping screen regions that you know have been rendered completely opaque at less depth than the current poly, and skipping those? I applied something similar to my 2d engine and got good, (approaching O(n),) results, but then, I’m no expert at 3d.
[/quote]
There is. In opengl it is called AlphaFunc. Java3d should have it somewhere in one of the Appearances attributes. It allows you to process or reject an incoming fragment depending on its alpha value. You can use it by rendering the geometry twice. First only processing opaque pixels with depth write on. The second pass rendering only transprent pixels with depth write off. That would look good in most cases, but are still not perfect.
[quote]Plus, I don’t think they’ve released the source code for the OSX implementation of J3d. So, I couldn’t really go about tweaking the code myself. And it would all get very platform-dependant.
Bah… …oh well. Thanks for the advice.
[/quote]
You don’t have to. Java3D allows you to change the geometry every frame. By rearanging the triangles in a back to front fasion using a bsp, you can sort the triangles within a Shape3D perfectly. Note that only sorting the triangles is not enough. Triangles can be overlapping in such a way that sorting is impossible. Then you need to split it up wich is what the bsp is for.
There’s not much new information, but on the left you have the figure without Transparency Blending, which is comparatively easy on the eye (or would be if diffuse lighting were working correctly,) on the right, the problems occur.
http://img394.imageshack.us/img394/8883/compare2pr.gif
[quote]Sorry, but getting someones source code to compile is way to much work. In particular since I’m guessing I have to download and intall java3d and possible java5. If you had a screenshot I could look at it.
[/quote]
Java3d yes, I don’t think java5. So much for write once, run anywhere…
[quote]Java3d should have it somewhere in one of the Appearances attributes. It allows you to process or reject an incoming fragment depending on its alpha value. You can use it by rendering the geometry twice. First only processing opaque pixels with depth write on. The second pass rendering only transprent pixels with depth write off. That would look good in most cases, but are still not perfect.
[/quote]
[quote]You don’t have to. Java3D allows you to change the geometry every frame. By rearanging the triangles in a back to front fasion using a bsp, you can sort the triangles within a Shape3D perfectly. Note that only sorting the triangles is not enough. Triangles can be overlapping in such a way that sorting is impossible. Then you need to split it up wich is what the bsp is for.
[/quote]
That should prove most useful, if I knew where and how to access and sort the geometry in this fashion, though I’m reasonably confident I can figure out the Appearance class. Could you point me in the right direction on the class/methods needed?
(Since you seem to be formidably informed, would you have any idea what could cause diffuse lighting to switch from 100 to 0% across an entire model depending on which way you look at it (except, for some bizarre reason, a tiny patch on the left rim of the helmet?))
EDIT: Oh, right, binary space partition.
Hmm.
View view = universe.getViewer().getView(); //SimpleUniverse
view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);
view.setDepthBufferFreezeTransparent(false);
Seems to solve the problem for me. I presume there is some ghastly hidden pitfall I should be wary of. Lighting still a problem, mind.
The diffuse lighting effects are based on the vertex normals. I have seen similar artifacts when the vertex normals are incorrect.
Mike
[quote]The diffuse lighting effects are based on the vertex normals. I have seen similar artifacts when the vertex normals are incorrect.
[/quote]
I’m almost certain that’s not the problem, as the diffuse lighting changes when the view rotates, which should, in theory, have no effect on the normals. Still, I’ll investigate.
Oh- one other item- is there some relatively inexpensive method of applying antialising just to the edges of the triangles, to avoid jag artifacts against the background?
It looks like the arms is not shown on the right. But why are you using Transparency Blending. The texture looks all opaque. Seems to me like your trying to do something the wrong way.
Have a look at javax.media.j3d.GeometryUpdater. Given the information in the javadoc you should find out how to change the verteces of a model.
Btw. RenderingAttributes contains the functions needed to manipulate alpha and depth buffer. View.setDepthBufferFreezeTransparent(boolean) overrides the attribute on the transparent pass. It’s nice they have added this. When I used Java3D last sorting of transparent Shape3D was not implemented yet. It sucked.
So is this solved? I have transparency working perfectly for NWN environments. I can cli pthe JNWN code and post it if it would be helpful. (Or you cna grab the whole source base from jnwn.dev.java.net)
Having checked the normals at runtime, they don’t seem to have been obviously tampered with. Lighting is still off. I’m going to download kduling’s viewer code again and see if I get the same bug.
[quote]It looks like the arms is not shown on the right. But why are you using Transparency Blending. The texture looks all opaque. Seems to me like your trying to do something the wrong way.
[/quote]
More than that, the shield is on the opposite side of the body from where it should be and the back of the head is visible through the helm. This texture is almost completely opaque, yes, but other models I’ve produced rely heavily on transparency support.
[quote]Have a look at javax.media.j3d.GeometryUpdater. Given the information in the javadoc you should find out how to change the verteces of a model.
[/quote]
I’ve been using that for geometry-by-reference (though that’s changed, but vertices were in correct order, witness the fact they displayed fine without transparency blended, they just weren’t being displayed in that order.
[quote]View.setDepthBufferFreezeTransparent(boolean) overrides the attribute on the transparent pass. It’s nice they have added this. When I used Java3D last sorting of transparent Shape3D was not implemented yet. It sucked.
[/quote]
Excellent…
[quote]So is this solved? I have transparency working perfectly for NWN environments. I can cli pthe JNWN code and post it if it would be helpful. (Or you cna grab the whole source base from jnwn.dev.java.net)
[/quote]
Much appreciated, I’ll go download the source. You didn’t run into any problems with lighting, did you?
[quote]More than that, the shield is on the opposite side of the body from where it should be and the back of the head is visible through the helm. This texture is almost completely opaque, yes, but other models I’ve produced rely heavily on transparency support.
[/quote]
Try to split the model into opaque and transparent parts and use 2 different textures. Don’t use blending on the opaque texture. That would solve most of the blending problems.
[quote]Try to split the model into opaque and transparent parts and use 2 different textures. Don’t use blending on the opaque texture. That would solve most of the blending problems.
[/quote]
It seems to be working well at the moment, but you’re right, a mixed approach would do no harm.
[quote]The diffuse lighting effects are based on the vertex normals. I have seen similar artifacts when the vertex normals are incorrect.
[/quote]
Although it doesn’t explain the bug I had with lighting before, when I used the Viewer code:
http://home.earthlink.net/~kduling/Milkshape/Viewer.java
I did discover that the normals were oscillating madly. I had forgotten to reset them to default values before joint rotation. After that, it works fine. Mea culpa.
Thank you all for your assistance, it was extremely helpful.
Looking at that picture, it appears as though all your normals are back to front to what they should be. This is pretty typicaly of the loader code reading triangles assuming clockwise ordering and J3D is rendering them using anticlockwise.
Worry not, it’s working fine atm. No complaints here.
Right. Terrain display is now causing headaches, probably because this is my first attempt at actually using large-scale transparency blending. At the rate this is going, I’ll have to make Jeff and Tom honorary authors for the code.
[quote]I have transparency working perfectly for NWN environments. I can cli pthe JNWN code and post it if it would be helpful.
[/quote]
On consideration, that would be greatly appreciated, rather than having to review the code at length. If you wouldn’t mind.
As far as I can tell, the real problem here is that the polygons I’m using to ‘fringe’ the terrain tiles are very close to the basic surface, so J3D has difficulty depth-sorting them properly. I can’t think of any simple remedy, though “…rendering the geometry twice. First only processing opaque pixels with depth write on. The second pass rendering only transprent pixels with depth write off”, would probably help.
I’ve attached a screenshot of the problem, and the terrain texture files. Grass should overlap on stone. The texture files have a central tile piece corresponding to UV (1/6, 1/6) to (1/3, 1/3), while fringe pieces adjoin this square.
Any thoughts?
I find that disabling the depth buffer under RenderAttributes helps significantly with the ‘blackouts.’ Does nothing for depth-sorting, of course.
Edit: Also, I think the problems with depth-sorting are not due to the closeness of the surfaces. I increased their seperation from 0.015x16 to 0.25x16, to the point where it was easily visible from man angles, and still find that about half the fringe polys were being hidden.