 Show Posts
|
|
Pages: [1] 2 3 ... 6
|
|
1
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-25 00:55:24
|
Sorry, was my fault. Was easy to fix at last. Just setting the initial TransformGroupId to 1 instead of 0  . I also changed the test class to make it able to be run with LWJGL, which was not possible because of the Swing thing. I hope you're not annoyed because of that. Marvin Thanks Marvin! No problems  , going to check it out in a little while... |
|
|
|
|
2
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-24 15:51:00
|
You can believe me - was a hell of work, and significant part of my contributions to Xith3D came that time when we at JProof made these apps.
Yes, I believe it was , results are amasing... Question to everybody... Can anybody ran Bleeding_Blending_test please? Same old version as it was before... I get latest xith from CVS and experiencing odd behaviour of transparencies.... Have difficulties to explain really  , just need to get it working "normally" to test new sorting... please look at it and advice... something like color buffer is not cleared every frame + improper culling I guess as well, since top shape is freezing on revers go (like it is drawn once and that's it)... anyhow very strange to me... Bohdan. Edit: and when I set shapes to be opaque - no animation is happenning at all  Like transform is not updated or something... |
|
|
|
|
3
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-23 20:32:33
|
For the additional Shape3D flags: Just ask . Thanks Marvin! 1. It is theoretically not possible to render mutually intersecting or self-intersecting shapes with standard OpenGL rendering modes.
2. The best one can do is to depth-sort geometry triangle-by-triangle, but it is too slow and even this does not guarantee correct result if some of triangles mutually intersect - you should cut trianges to smaller before sorting.
3. There are some combinations of alpha test, depth test and additive alpha blending that produce more or less good result, but in some angles they still do not work.
Alright... understand, that one I going to do going to assume transparent objects to be flat, which is mostly the case... and it should give much better results in general, especcialy if there is no intersection, though not always will be 100% correct... 4. Most interesting. There are CORRECT TRANSPARENCY rendering techniques that can be implemented with modern cards and fragment shaders. At least one technique is called "Depth Peeling" which gives 100% correct result, but it is multipass (number of passes depend on the correctness required and degree of shape self-intersection).
Alright.. yep, sounds very interesting!, haven't heard of something like that exists.... Great to know! OK, I will disclose one link that might be intersting for you: take a look at http://www.jproof.at/3d/. All examples there use Xith3D for the rendering. You should note that these examples are relatively old, and require JDK 1.4.2 (I think it will be installed on demand), so even don't ask me to update them. If you can run them (and I believe it is possible - some people from this forum confirmed they are running OK), check the House example, and take a closer look to the trees: they use 2-pass rendering with alpha test and render-to-depth-buffer, if I remember correctly. Also try to take out the house levels and you will see the transparency behavior when the level disappearing. Thanks a lot for link and information! It was great to see, very nice done! Wokred fine, no problems. And transparencies handled surprisingly really nice there! It was good material to see how things can be possibly done! |
|
|
|
|
4
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-23 18:53:30
|
Sorry guys, I was late with the deadline on my work, so have to disappear for a while, but now I'm back and going to do that thing. I see Yuri is back! Glad to see you again, Yuri! BTW, Yuri, any objection or advices on adding another comparator speccially for sorting transparencies as discussed here above? It is not going to be ideal, but should serve much better then current back_to_front comparator does, at least in most of the cases. Will try to tuch as less as possible behind the sorting itself, but I may need some information to be specified for Shape3D to speed the things up (some flags etc..., maybe vector...) Well I just get back to that thing so I should have some good enough implementation ready in 1-2 days. Basicaly, it will not break anything at all, for sure, just that the user will be able to choose one more sorting method for transparencies besides those existent. Bohdan. |
|
|
|
|
5
|
Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph
|
on: 2006-10-14 21:08:16
|
Only remember - do that thread safe way, sync with rendering loop by means of for example "synchronized (myVirtualUniverse)" as Marvin suggested, or any your way, otherways, if you don't - you may get unpredictable or(and) unbelivable results |
|
|
|
|
7
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-14 18:35:48
|
Good example of the delegation pattern applied in team coding So, can I assume that this task is assigned to me?
please do contributions will always be welcome.. as long as they do not introduce more bugs than features.. Ok, so I'll post here when I ready. |
|
|
|
|
8
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-14 18:24:05
|
It is BoundingBox, not BouncingBox , yes, you are right , sorry... Yes, I know, there're really few transparent shapes. And activating BoundingBox for flat shapes could be a good way. But we must be carefull not to activate it for all shapes.
Yes, of course, bounding boxes will be only where appropriate. Are you maybe interested in doing that?
Well, actually why not, i thing i know exactly what and where to correct, so I can do that. The only thing is at the moment I'm really busy with my work (at least till tuesday), so I will do that slowly, if that's ok? I think I probably can do even little bit different way, not touching bounding boxes even... just one extra flag to be set in Shape3D... well, I need to think a little first (and I will let know which way I planning to do that), but anyways - this is relatively easy to do one way or another... So, can I assume that this task is assigned to me? Bohdan. |
|
|
|
|
9
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-14 18:00:00
|
Well, you can't have a generally "correct" sorting criterion. Consider this case: 1
2
3
4
5
| xxxxxxxxx
x
aaaaaa x
x
xxxxxxxxx |
Where the x-es describe one shape and the a-s another one. These ones can't be universally sorted. So I guess bounding sphere centers as the criterion and depth buffer writing fix are the best achivable way. Marvin Yes, totaly agree with you!!! Bleeding_Blending will start looking much better if you set depth writing off - already. And if you have 0.5 transparency, for two planes - you will see no difference even if wrong sorted - yes, this is pretty good already. There is no universal sorting really (which is fast enough), agree, but still consider that mostly transparent objects are "flat planes", and to have sorting based on bouncing spheres (well, even not that - on their centers only!) is to rough.. i think. Why not to get use of BouncingBox - it is not used in some reason in xith, everything is done with bouncing spheres. But when calculating bounds and if for flat shapes you use bouncing box rather then spehere the you can check if two atoms bounds are bouncing boxes - you can do very fast and much more precise sorting that with the spheres centers. You don't have much of transparent objects in the scene, just few really, so even if sorting will be little slower that current implementation - it will not affect anything really. Bohdan. |
|
|
|
|
11
|
Java Game APIs & Engines / Xith3D Forums / Re: Transparency problems
|
on: 2006-10-14 17:23:25
|
I'm on the track of Xith's Transparency problems demonstrated in Bleeding_Blending test. It has to do with the depth test.
Little correction here. You probably meant that "Depth Writing" have to be off when drawing transparencies, but not the depth test itself! So, that when drawing transparencies (and when they are sorted already from back to front) - they will still be depth tested against the values in depth buffer (filled in when the opaque shapes where rendered) but transparencies will not modify the depth buffer (this is what you want to achieve setting depth buffer writing off) - then this will work fine!!! In general, you set Depth test off only in very special cases really. |
|
|
|
|
12
|
Java Game APIs & Engines / JOGL Development / Re: Using JOGL with my favorite IDE (Eclipse)
|
on: 2006-10-12 16:27:25
|
Same thing happens to me, agree it is a real pain espessially with gl.glXXXX - on my (not to powerfull) PC Eclipse will hang up for couple of minutes Hi,
I don't use eclipse (and i hope I won't have to) but that's a matter of taste... But I can anwser you on the Netbeans part.
1. You have to link javadocs to the librairy ( in fact it must be the same in Eclipse so you'll have more explicit arguments for the methods.
2. The completion is quite fast (not as fast as a completion on a class with two methods but only 1 or 2 secs).
I can confirm that linking javadoc etc... will not help with autocompletion (on Eclipse at least), argument/parameters would read properly though but only that... |
|
|
|
|
14
|
Java Game APIs & Engines / JOGL Development / Re: Drawing "Overlay" problem...
|
on: 2006-10-11 03:58:17
|
Can you post your code or what depth mask and did you use to draw this?
Basically, the problem was that somewhere in the drawing procedure, before I draw "overlay" shape, I had writing to depth buffer disabled, consiquently "overlay" shape never appeared in depth buffer (and I thought it was), so when transparencies where drawn next, they just was not checked (depth test) against this shape and went over it.. that's it... I just by mistake left writing to depth buffer off, and forget about that and couldn't spot it for a while  . |
|
|
|
|
17
|
Java Game APIs & Engines / JOGL Development / Drawing "Overlay" problem...
|
on: 2006-10-09 20:12:59
|
Hi guys! Question from total noob... If I want to make sure that I will draw a shape over the staff which is already drawn is it enough to clear the Depth Buffer before I draw that shape? It works for me fine that way provided that I didn't draw any transparent shapes before (especially transparent & having depth test / depth buffer off). But if I do draw transparent shapes and played with the depth buffer before, than even if I clear depth buffer before I draw the shape, the one I want to be in front, some transparent shapes which I draw before will pop up in front.... Why? Thanks in advance... Bohdan. Edit: actually, I a bit wrong... not that transparent will pop up in front, but that shape I draw the last, will be drawn like it actually went through depth test (though the depth buffer should be clear at this stage already).... |
|
|
|
|
19
|
Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph thread safety
|
on: 2006-10-06 22:16:24
|
|
Wouldn't it impact performance, such way of synchronization?
I feel just "in loop synchronizations" as we used to are fatser (not sure though)
Those mutex monitors or whatever way they are called - migth be slow... Or I am wrong?
|
|
|
|
|
20
|
Java Game APIs & Engines / Xith3D Forums / Re: RenderBin optimization
|
on: 2006-10-05 05:03:30
|
Whaah. It isn't working anymore (I didn't swap the planes so far) . Only if I disable the sorting. Hmm... Maybe the clue really is in the comparators.  It's a pitty...  But anyhow, to move forward. I checked default comparator for sorting transparencies, and yes... it seems to be far from being universal... The idea is, that centers of bounding spheres are taken and just distance is compared to the camera location... that's it. If you think about this - it will cause just exactly same behaviour as we see in the test..... Top plane would be top till the moment it get far away enough so that bottoms' plane bounding sphere center become actually closer to the camera then the top one.. - which is totaly wrong, of course. So: 1. top one (BLUE) will be drawn first (instead of to be second) and will be blended with the background. 2. bottom one (GREEN) drawn next and where it is not overlapping top one - is blended with background, but !!! - where it is overlapping top one (onscreen pixels wisely) - will not be drawn at all because it will not pass GL depth test! - so we see still BLUE plane there blended with the background. That's it. Comparators seems to be pretty simple... to simple maybe... |
|
|
|
|
21
|
Java Game APIs & Engines / Xith3D Forums / Re: RenderBin optimization
|
on: 2006-10-05 04:04:55
|
|
It says for "sortBackToFront( Point3f point )":
/**
* Sort the render bin from closest to furthest using bounding shpere center as reference point.
* @param point
*/"
May be this is the clue?
And another thing BTW, Marvin, in that test that worked for you, can you try swap those botom and top planes as you adding them to scenegraph and see if the test stil works?
Edit:
No I don't have the very recent version, but I will try it, of course. But still would be interesting if you can swap those shapes in the test and confirm that it is still working..
Edit2: me getting recent version now...
|
|
|
|
|
22
|
Java Game APIs & Engines / Xith3D Forums / Re: RenderBin optimization
|
on: 2006-10-05 03:55:07
|
|
It just seems I was wrong before saying that test case worked, I discovered that it is working anyhow since I have set sorting for transparencies NONE when was playing with it (and forget about that)!
So basically, switch from one sorting to another doesn't seem to make a difference (regarding transparencies)... When I switching sorting OFF totaly - yes, that blending test case working, but just because order is correct straight away... In general case it will not work...
What I mean... I most likely was wrong blaming QickSort as for wrong sorting...
I asked about comparator since thay play role in sorting too... hmmmm... strange...
|
|
|
|
|
24
|
Java Game APIs & Engines / Xith3D Forums / Re: RenderBin optimization
|
on: 2006-10-05 03:24:20
|
Well.. I uncomment one line and commented another in RenderBin (few occurances)... from: 1
2
| quickSort(buckets, 0, curSize-1, <comparator>); |
to: 1
2
| Arrays.sort(buckets,0,curSize, <comparator>);
|
(this is from a bit older version of xith) Well... but I'm sort of tired or stupid or smth.. but there is something strange happening as well here, that I can't explaine... Give me little while, just want to make sure... |
|
|
|
|
26
|
Java Game APIs & Engines / Xith3D Forums / Re: RenderBin optimization
|
on: 2006-10-05 02:49:00
|
Is it actually working? Did you test it? I didn't know if it is working on my current code state, which I haven't committed or on the one already committed. No-no, I didn't tested it yet myself!!! But you said in you first post you did and it worked for you! So I suspect the Quicksort did anything wrong, which the mergesort does correctly. Don't know. But I think, this will have solved it.
I believe you are right. It was more or the less obvious anyhow that the problem is with the sorting the transparencies. And I guess (well, basing on changes you said you did) QuickSort was not properly sorting transparencies from back-to-front!!!! That's it!!! Thanks Marvin for finding that! I believe many people will confirm that it was long term headacke with the transparancies!!! @lilian: can you have a look at it and confirm? It was good algorithm, anyhow, and with the little fix it may become needed at some stage again.. It really worth fixing... Sorry  Bohdan. Edit: I said: "QuickSort was not properly sorting transparencies from back-to-front!!!!" I really meant to say: "QuickSort was not properly sorting!!!!" |
|
|
|
|
27
|
Java Game APIs & Engines / Xith3D Forums / Re: RenderBin optimization
|
on: 2006-10-05 02:15:53
|
I totally agree with Marvin! Transparency problems like one demonstrated in Bleeding_BlendigTest existed at least for a year or even more!!!, I can garantee that. What about render bins - they were always properly ordered till some very recent changes (I belive when you, Marvin was optimising staff with bins, bins by mistake got swapped), this had happen just back one-two weeks ago. Yes, this totaly destroyed transparencies  . Again I can confirm that too. But when renanse fixed it, things got back to "normal", still with those problem like with Bleeding_BlendingTest happening. And only now, that BlendingTest start working properly! It was simple test case, and it doesn't meen yet that the the problem is really fixed, but I hope so of course. I will check other problems (of the same nature) I had and see if it is sorted now, if it is - well, Marvin, I don't know how - but you did a miracle somehow!!! Bohdan. |
|
|
|
|
30
|
Java Game APIs & Engines / Xith3D Forums / Re: DisplayLists: 20% performance boost in MultiCubeBenchmark ;D
|
on: 2006-09-24 18:31:42
|
Well, the game won't crash, if you change any of the shape's properties including the Appearance's ones, but it won't have any visible effect, if you change a property after the first frame. So in other words: A Shape3D is considered to be static, when you're not planning to change any of it's properties. Of course you may translate, rotate or scale it using a TransformGroup... no problem.
Alright, now understand, thanks I'm currently thinking about refreshing the static shape's display list when a property has changed. I'm also planning to add a third type called "AUTO". With this type the renderer looks for modifications on the shape and if nothing has happened to the shape's properties for a certain amount of frames, the shape's type is automagically switched to STATIC (just as Amos suggested). This would be a good default. Maybe a static flag on the Shape3D class would then make sense, telling if this automatic switch should be performed.
Yep, sounds good to me |
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
