is Java3d dead and what are the alternatives?

[Jeff]

First attempted comparison:
http://www.web3d.org/x3d/content/examples/StudentProjects/AllenDuttonVillage.x3d

Ran with the Xj3d browser with the -j3d flag. Got frame rate whiel rotating of app 8.5

Ran again with Avaitrix, blew up with the following exception…

java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at org.j3d.geom.CharacterCreator.createNewGlyph(CharacterCreator.java:418)
at org.j3d.geom.CharacterCreator.createCharacterTriangles(CharacterCreator.java:162)
at org.j3d.renderer.aviatrix3d.geom.Text2D.setText(Text2D.java:609)
at org.web3d.vrml.renderer.ogl.nodes.text.OGLText.setupFinished(OGLText.java:165)
at org.web3d.vrml.renderer.common.nodes.shape.BaseShape.setupFinished(BaseShape.java:399)
at org.web3d.vrml.renderer.ogl.nodes.shape.OGLShape.setupFinished(OGLShape.java:352)
at org.web3d.vrml.renderer.common.nodes.BaseGroupingNode.setupFinished(BaseGroupingNode.java:319)
at org.web3d.vrml.renderer.ogl.nodes.group.OGLTransform.setupFinished(OGLTransform.java:191)
at org.web3d.vrml.renderer.common.nodes.BaseGroupingNode.setupFinished(BaseGroupingNode.java:319)
at org.web3d.vrml.renderer.ogl.nodes.group.OGLTransform.setupFinished(OGLTransform.java:191)
at org.web3d.vrml.renderer.common.nodes.BaseGroupingNode.setupFinished(BaseGroupingNode.java:319)
at org.web3d.vrml.renderer.ogl.nodes.group.OGLGroup.setupFinished(OGLGroup.java:159)
at org.web3d.vrml.renderer.common.nodes.core.BaseWorldRoot.setupFinished(BaseWorldRoot.java:270)
at org.web3d.vrml.renderer.ogl.nodes.core.OGLWorldRoot.setupFinished(OGLWorldRoot.java:149)
at org.web3d.vrml.renderer.CRMainSceneBuilder.endDocument(CRMainSceneBuilder.java:546)
at org.web3d.vrml.renderer.ogl.OGLVRMLSceneBuilder.endDocument(OGLVRMLSceneBuilder.java:406)
at org.web3d.x3d.jaxp.X3DSAVAdapter.endDocument(X3DSAVAdapter.java:496)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:786)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endDocument(XMLDTDValidator.java:990)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:564)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1899)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1803)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipSpaces(XMLEntityScanner.java:1304)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(XMLDocumentScannerImpl.java:1253)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:372)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:844)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:774)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1255)
at org.web3d.parser.GeneralisedReader.parse(GeneralisedReader.java:246)
at org.web3d.vrml.nodes.loader.DefaultWorldLoader.loadNow(DefaultWorldLoader.java:145)
at org.web3d.vrml.nodes.loader.DefaultWorldLoader.loadNow(DefaultWorldLoader.java:95)
at org.web3d.net.content.Utf8ContentHandler.getContent(Utf8ContentHandler.java:114)
at org.ietf.uri.ResourceConnection.getContent(ResourceConnection.java:297)
at xj3d.browser.Xj3DBrowser.load(Xj3DBrowser.java:884)
at xj3d.browser.Xj3DBrowser.run(Xj3DBrowser.java:1222)
at java.lang.Thread.run(Thread.java:608)

Will try some other examples.

[Jeff]

Next test:

http://www.web3d.org/x3d/content/examples/StudentProjects/PlayRoom.x3d

7 to 8 fps on Java 3D
12-14 fps on Aviatrix BUT the floor textures, which rendered properly in J3D, were all messed up in Aviatrix.

These are not terribly complex scenes. Honestly, getting 8 to 25 FPS on a machine which gives me 250fps on a full NWN map strongly suggests to me that your bottleneck is NOT your renderer but merely that the choice of renderer is in some minor way impacting your primary problem.

(My first guess would be memory consumption and that the Xj3D veiwer is gobblign up memory in its own inetrnal structures to represent the data in X3D format. I can easily believe that J3D might be using a bit more memory then some other scene graph, its has some pretty complex internal structure itself. In general J3D apps dont maintain other scene description structures in parallel to the J3D ones.)

Anyway, if you can point me at source I may do some basic profiling to prove the point…

[Jeff]

Odd program. very unstable performance wise

I moved max mem up to 900M and removed the other -XX flag from both.

I now get apout 100 - 250fps from J3D moving in and out and
125 - 400 fps for aviatrix moving in and out

BUT

If I keep the (minorly) complex play room onscreen and move side to side I get only 100-150 fp from Avaitrix and 200 -400 fps from J3D!

There also appears to be some serious memory leak problems in this app as while I was typing this, Aiviatrix dropped to 14 - 16 fps on the sideways test. I havent tried it with J3D yet but, as thats the range I was geting initally before I doubled memory, Id guess Id get a similar drop over time from J3D.
I’m willing to postulate that, in any event.

Short answer:

This app is very unstable and inconclusive as a benchmark. Depending on what you are doing and when either API can appear up to 2x faster then the other. My gut says that Aviatrix in general does better on scenes wher there is not a lot of veiw frustrum clipping and J3D pulls out ahead when there is a lot of view frustrum clipping. That would explain what I’m seeing but its far from conclusive due to the general instability of the tests.

More importantly, the two renderers do not produce the same visible results and there is no gaurantee that Aviatrix, in fixing its mapping problems, woud retain the same render characteristics.

I still find it perplexing that this app renders scenes much less visually complex then an NWN map and without the dynamic animation at significantly slower rates then JWNW renders. (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently… but that wouldnt work for a real game.)

Finally, its clear to me that bad memory management issues in this App are complicating the entire test.

[tom]

@Jeff

When the scene gets bigger there is potenially more state switches and the scenegraph can sort this out for you. Even so, scenes in games are usually quite small.

Compared to what? They are among the most complelx I’ve ever dealt with…

Take an indoor game as an example. After disabeling what is not visible using pvs or portals you’ve left with a couple of rooms including content. It’s not that far off from what you can reproduce with a benchmark.

Microbenchmarks, like the one made by java cool dude will give a pretty good indication of how the performance will be in a real game.

Not knowing the microbenchmark in question I cant comment. In genreal microbenchmarks fail to predict real-app performance because they do not act like real apps. Its really that simple.

The most common “look how slow J3D is” benchmark I see… and I see this over and over, is a pure pixel throughput benchmark where all triangles drawn are visible in the rendered view. These are by definition totally worthless.

Ok, you’ve made the view-frustum culling point over and over again, but I disagre. Every engine you can compare J3D against will have frustum culling, and you’ll expect it be fast. I don’t believe J3Ds implementation is so much better than all the others, that it will have a huge effect on the rendering speed. Given that it is more or less a constant, you don’t have to take this into consideration when doing a benchmark.

I know you’ll disagre so I’ll ask now: What makes J3Ds view-frustum culling so much better than the others?

From what I’ve seen and heard, J3D is slow.

Again, point me at a real benchmark and we can discuss it. Oterhwise this is just assertion and mythology. (And by ‘point’ I mean give me source code so I can do a proper analysis. Its quite easy to make J3D performance bad by using it badly… This is true of ANY API.)

EDIT: Oh and I suggest if what you say is true, then you havent seen very much in J3D. Certainly you havent seen Shawn Kendall’s demos we showed every year for years at GDC…

Ah yes, the GDC demos. Well I’ve seen the videos, but never got my hands on anything I could actually run. Please post a link if you’ve got one.

Besides, I’ve made a game with J3D and can draw my own conclusions.

I still find it perplexing that this app renders scenes much less visually complex then an NWN map and without the dynamic animation at significantly slower rates then JWNW renders. (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently… but that wouldnt work for a real game.)

Why do a static scene render more efficiently if it is represented as a BSP?

[Jeff]

@tom

@Jeff

When the scene gets bigger there is potenially more state switches and the scenegraph can sort this out for you. Even so, scenes in games are usually quite small.

Compared to what? They are among the most complelx I’ve ever dealt with…

Take an indoor game as an example. After disabeling what is not visible using pvs or portals you’ve left with a couple of rooms including content. It’s not that far off from what you can reproduce with a benchmark.

Your getting confused by the term “complexity”. Its a lot more then just polygon count. Its the comlexity of the organization of those polygons. How many are in or out of the view frustrum at one time. How easy it is to desitinguish one from the other, etc.

A microbenchmark is typically way too un-complex in these areas.

Microbenchmarks, like the one made by java cool dude will give a pretty good indication of how the performance will be in a real game.

Not knowing the microbenchmark in question I cant comment. In general microbenchmarks fail to predict real-app performance because they do not act like real apps. Its really that simple.

The most common “look how slow J3D is” benchmark I see… and I see this over and over, is a pure pixel throughput benchmark where all triangles drawn are visible in the rendered view. These are by definition totally worthless.

Ok, you’ve made the view-frustum culling point over and over again, but I disagre. Every engine you can compare J3D against will have frustum culling, and you’ll expect it be fast.

You realize you just FIATed away the question by saying “Im going to ASSUME the other API asi as good at view frustrum culling as J3D”?

Thats not an argument, thats presuming the answer you want.

The fast of the matter is there is a LOT of stuff in J3D to make the view frustrum cullign efficient. It has a highly efficient bouding volume system, for instance, thats used both by the culling and by the pick code.

I don’t believe J3Ds implementation is so much better than all the others, that it will have a huge effect on the rendering speed.

Your doing it again. Arguing your beliefs, not facts. In fact, what your really saying is “I BELIEVE this so I refuse to consider testing that belief.”

Good argument for religion, Lousy for science.

I wont argue your beleifs or religion with you. You can believe the moon is blue cheese. Its your business.

From what I’ve seen and heard, J3D is slow.

Again, point me at a real benchmark and we can discuss it. Oterhwise this is just assertion and mythology. (And by ‘point’ I mean give me source code so I can do a proper analysis. Its quite easy to make J3D performance bad by using it badly… This is true of ANY API.)

EDIT: Oh and I suggest if what you say is true, then you havent seen very much in J3D. Certainly you havent seen Shawn Kendall’s demos we showed every year for years at GDC…

Ah yes, the GDC demos. Well I’ve seen the videos, but never got my hands on anything I could actually run. Please post a link if you’ve got one.

They belong to Shawn. Ask him.

JNWN is a project right here you can grab the CVS of.
https://jnwn.dev.java.net/

To run JNWN you will need a copy of the NWN data. You can either get that from an NWN installation or download it here:

http://nwn.bioware.com/downloads/linuxclient.html#lininstall

Besides, I’ve made a game with J3D and can draw my own conclusions.

A poor workman blaims his tools. And thats ALL I’m going to say on that.

Other then that you can ask others how often the “I KNOW Java is slow 'cause I tried to write something in it and it was slow” argument comes up from the Java-ignorant who stick their noses in here.

Im honestly sick and tired of dealing with it.

I still find it perplexing that this app renders scenes much less visually complex then an NWN map and without the dynamic animation at significantly slower rates then JWNW renders. (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently… but that wouldnt work for a real game.)

Why do a static scene render more efficiently if it is represented as a BSP?

Your kidding, right? Or are you not familair with BSP trees?

A BSP is a terrific structure for determining incredibly fast what is “behind” the view and thus eliminating approximately half the scene from ANY consideration or furtehr testing for inclusion in the render set.

Furthermore, the BSP makes finding front to back order trivial, which helps with things like distance-culling.
There are other things you can do with it too, some of which are less imprtoant in these days of big Z buffers, but others which can still be important. (Such as ordering for scenes with a lot of transparency.)

Unfortunately, it only works for static geometry.

EDIT: On considering this whole exchange, I do have one more things to say.

Kesselman’s Definition of Religion: Religion is a belief that has been invested with an emotional stake by the beleiver.

IMHO thats exactly what we have here. You tried to write a program. You didnt hit your performance goals initially. Youd ecided it was the fault of the tools and thus vindicated yourself Yoiu now have an emtional stake in that belielf. And therfor there is little point to trying to discuss it.

Already been there, done that, I know from experience its pointless, Believe whatever makes you feel good, just make clear to others thats what you are spouting-- pure religious belief.

If you have honestly blinded yourself to the poitn where you cant understand why one API, which spends more effort on view frustrum culling, as opposed to another that spent less on such culling, would process scenes with NO view frustrum cuilling slower but scenes with ALOT of view frustrum cullign faster, then I really don’t see how I can help you understand.

I think its time to do this…

PLONK

[blahblahblahh]

Since I’m normally the one arguing like Jeff above, and he normally chimes in after I’ve had a few rants, I thought I’d return the favour

IME, java3d performance at the moment is bad, really bad, on most non-trivial scenes on many computers, but not all. Quite a few java3d games came my way because of JGF and got tested on a wide variety of machiens with similar processors (within factor of 2 CPU speed, and factor of 2 performance gfx cards) got FPS that on some machines was 40+ and others was 0.25 or worse, consistently. I can think of several explanations for this, all of which come down to “insufficient time spent testing and fixing scenarios where it’s behaving badly, and could be driver bugs or could be SG bugs”, which is par for the course in a typical OSS project. From conversations with people on the j3d team and others at sun, it sounds as if that kind of task isn’t on the agenda much, they’re instead concentrating on doing more for the people for whom it already works (adding features etc) (yes? no?).

That, of course, is a major problem for games devs who have to support all machines, as opposed to e.g. research centres where they only have to support literally a handful of make/model combinations. YMMV, I’m only passing on what I gleaned - it may no longer be the case. But, given how much time it takes to do that sort of thing, and how it doesn’t impact some users at all, tis easy to see how it might get deprioritized.

OTOH…I have to say that many of the complaints against J3D do seem based mostly on hearsay and theoretical extrapolation (which is what I just did above: I’ve seen a dozen or so recent J3D games all have the same severe problems, so I’m guessing that it’s not just coincidence and is a general problem - I may be completely wrong). The Aviatrix3D is the only stuff I know of that we can currently use for side-by-side comparisons, and I wonder how much this has to do with the way most people I know who’ve tried Xith3D for their game seem unwilling to go back to Java3D, even for a test? I’ve tried many times to get more people to try both side by side, but as soon as someone tries Xith seriously and finds they can use it at all (i.e. their code isn’t too dependent on missing features from J3D) they don’t seem to go back.

In the meantime, we’ve got a feature-list side-by-side comparison, which I’d appreciate any updates and/or additions for:
http://javagamesfactory.org/views/view-library-category-features?category=Graphics%20Engines

[tom]

@Jeff

You realize you just FIATed away the question by saying “Im going to ASSUME the other API asi as good at view frustrum culling as J3D”?

Thats not an argument, thats presuming the answer you want.

The fast of the matter is there is a LOT of stuff in J3D to make the view frustrum cullign efficient. It has a highly efficient bouding volume system, for instance, thats used both by the culling and by the pick code.

There are many game engines and scene graphs out there. Many are commersial engines used in real games. No, I don’t know how they’ve implemented their culling, because that information is usually not available. No one knows for sure whos the best, not even you. But I find it logical that J3D is not the only one who has mastered this technology.

I don’t believe J3Ds implementation is so much better than all the others, that it will have a huge effect on the rendering speed.

Your doing it again. Arguing your beliefs, not facts. In fact, what your really saying is “I BELIEVE this so I refuse to consider testing that belief.”

Good argument for religion, Lousy for science.

I wont argue your beleifs or religion with you. You can believe the moon is blue cheese. Its your business.

Facts are hard to come by. Seems to me you are just arguing your beliefs.

Besides, I’ve made a game with J3D and can draw my own conclusions.

A poor workman blaims his tools. And thats ALL I’m going to say on that.

Other then that you can ask others how often the “I KNOW Java is slow 'cause I tried to write something in it and it was slow” argument comes up from the Java-ignorant who stick their noses in here.

Im honestly sick and tired of dealing with it.

I made a real game with J3D. From my experience I found J3D a bit on the slow side. I don’t see myself as a newbie when it comes to computer graphics, but I might have high thoughts about myself.

I still find it perplexing that this app renders scenes much less visually complex then an NWN map and without the dynamic animation at significantly slower rates then JWNW renders. (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently… but that wouldnt work for a real game.)

Why do a static scene render more efficiently if it is represented as a BSP?

Your kidding, right? Or are you not familair with BSP trees?

A BSP is a terrific structure for determining incredibly fast what is “behind” the view and thus eliminating approximately half the scene from ANY consideration or furtehr testing for inclusion in the render set.

Furthermore, the BSP makes finding front to back order trivial, which helps with things like distance-culling.
There are other things you can do with it too, some of which are less imprtoant in these days of big Z buffers, but others which can still be important. (Such as ordering for scenes with a lot of transparency.)

Unfortunately, it only works for static geometry.

As long as you don’t end up splitting the geomtry to much. Static geometry is best rendered in big chunks.

EDIT: On considering this whole exchange, I do have one more things to say.

Kesselman’s Definition of Religion: Religion is a belief that has been invested with an emotional stake by the beleiver.

IMHO thats exactly what we have here. You tried to write a program. You didnt hit your performance goals initially. Youd ecided it was the fault of the tools and thus vindicated yourself Yoiu now have an emtional stake in that belielf. And therfor there is little point to trying to discuss it.

I finished that program, and the performance was as expected. I’m not blaming anyone. It was an experience that I now draw my conclusion from.

If you have honestly blinded yourself to the poitn where you cant understand why one API, which spends more effort on view frustrum culling, as opposed to another that spent less on such culling, would process scenes with NO view frustrum cuilling slower but scenes with ALOT of view frustrum cullign faster, then I really don’t see how I can help you understand.

I think its time to do this…

PLONK

I draw the conclusion that J3D has a high overhead. There is no evidence that it will catch up as the scenes get more complex.

[princec]

One day someone will show me something fast and modern looking running in Java3D One day.

Cas

[Herkules]

I failed to do so …

But Shawn Kendall always has stuff that looks so much better! And its Java3D as well. There has to be a secret somewhere…

[Orangy_Tang]

@Herkules

There has to be a secret somewhere…

Yes, his stuff is never playable or publically available. :

If Java3D really was so shit hot we’d have seen something amazing created with it already. All we end up with is rhetoric and empty promises.

[princec]

Show me the money.

Cas

[Herkules]

@Orangy Tang

@Herkules

There has to be a secret somewhere…

Yes, his stuff is never playable or publically available. :

Yes and no … not publically available.

But at least I have been an eyewitness (JavaOne2003) of these things. No cheats, his stuff ran on the same machine as my FlyingGuns demonstration. Yet much smoother, do cell-shading, shadow-casting … with 70fps.

FlyingGuns hardly reached 25fps running very unsmooth…

There must be a secret …

[princec]

Secrets are no good. The whole idea of Java3D was that it was supposed to be clever and do all the secret stuff for you.

Cas

[aNt]

ok im going to have another play with j3d… just couldnt get most of it working last time- no real docs. but then
there none for most api anyways :)… jme is the best of them so far i have found, xith is also very good but needs
help with ui… at the end of the day use whatever… im sure j3d is rocking- it was just abit to closed
for my liking and no MacOSX support until Panther… worth a look at again is my thought… wonder if it works on
Tiger??

blablabla im not sure about that link- seems abit out of date… maybe im reading it wrong…

[Jeff]

@princec

Secrets are no good. The whole idea of Java3D was that it was supposed to be clever and do all the secret stuff for you.

Cas

Heh. You knwo better, right Cas?

The more compelx a system is, generally the more sublte the knobs are that have to be twisted

It does a lot of stuff for you yould have to write yourself, but you still have profile and tweak. In some ways you coudla rgue you need to do a bit mreo rpofiling sicne you know less innately about the actual interior.

Shawn has never been shy about sharing his knwoledge though. Im sure he’d be happy to answer any and all questions.

[Jeff]

@Orangy Tang

@Herkules

There has to be a secret somewhere…

Yes, his stuff is never playable or publically available. :

All of Shawn’s stuff has been publicly playable at the demos we’ve done (GDCs and JavaOnes).

Up til now Shawn has been paid to create demos, not releases. As a result there has been no budget or incentive to get it to relasable form. Anyoen who has actually done a real release should be appreciative of how much relase engineering really needs to be done to make anything of significant complexity releasable in a way that will install sucessfully on the majority of platforms out there.

Shawn is working on an actual product. That will likely be the first thing of his that is made releaseable.

Meanwhile as Ive offered before youcna doewnload the JWN base as I work on it if you like. i am not anywhere near a real release but I trust you guys to be technical enough to handle that…

[Jeff]

My summation:

Using Java3D is a trade off. Its a scene graph API talking to a closed renderer. Thsi means it has certain limitations:

You can get better performance with a custom renderer taking game specific cheats. Thats a given.

Similarly,in some situations, you may be able to get better culling performance out of game and data specific dodges.

Finally it will likely always lag at least a little behind the bleeding edge of techniques you can do on raw OGL or D3D.

Java3D also carries a legacy of beign designed around VRML and Vis/Sim type apps and thus carries some code with it that is probably not needed in a game environment. Thus I am quite willing to believe there is some size bloat, though in my experience its trivial next to the size of the data we deal with in 3D applications.

But I’ve looked and seen no evidence that Java3D is not as fast or faster then any other equally general and equally correct scenegraph API. It is a mature API that has been around long enough to be mostly bug free and there is a fair body of knowledge available, thanks to the pioneering work of people like Shawn, as to how to effectively use it.

Now that there is a team on it again its is continuing to evovle at what I cosndier a reasonable pace. One thing to remember is that the team is very serious about maintainign a foward direction with abckward compatability for the API. This means once they commit to a mechanism they really really do not ever want to have to chnage it out from under users. This means they sometimes purposefully delay adding features where the standards are not eyt clear. A good example of this was shaders where they waited until glsl happened.

In the end, you have to decide what is the right tool for you. There are many good reasons not to use Java3D. Maybe you are doing soemthing ins sucha limtied space you really cant afford the weight of the API. (Java3D would be a abd chocie for today’s cell phones or most PDAs for instance.) Maybe your render needs are so simple then the over-head and API complexity isnt worth it. (2D games are best done right ontop of OGL for instance.) Maybe you are doing a cutting edge type product that has to release soon and can’t afford to wait for Java3D features that don’t exist yet. (For JNWN I really need multi-pass rendering because I really want to avoid the over-head of calculating dynamic shadow volumes on the CPU. As it happens, JNWN doesnt have a hard release date and, after seeing the J3D team’s plans, I feel I can afford to wait for it. But someone who had to release this Christmas might not.)

But chose your API for the right real reasons, not because of unprovable (or maybe even disprovable) myths like “Java3D is slow.”

I’m done.

[Jeff]

@aNt

ok im going to have another play with j3d… just couldnt get most of it working last time- no real docs. but then
there none for most api anyways :)…

I use the Javadocs and have found them very complete.

Byond that if you have questions feel free to ping me

[Bombadil]

Thanks Jeff for all your valuable infos.

Regarding the sad Winblows Vista matter of a possible OpenGL discrimination:
One thing which could also become a plus then for Java3D - and it has some ironic in it - is its possibility to use either OpenGL or D3D with the matter of a runtime switch.

[blahblahblahh]

@aNt

blablabla im not sure about that link- seems abit out of date… maybe im reading it wrong…

If that’s the case, you need to tell me what needs changing. I can’t do much with “seems a bit out of date”, I’m afraid