• Advertisement
Sign in to follow this  

Unity [java] introducing ogre4j - Java native interfaces for OGRE

This topic is 4559 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello GameDev.net community, I proudly introduce the growing Java native interfaces ogre4j for OGRE. I found some threads about OGRE on GameDev.net and thought that maybe someone wants to know that there is a new "alternative" to Java3D. The ogre4j team invites everybody to join the development of the JNI bindings for the very good render engine OGRE. The sources are at a early stage and at least 30% of the public interfaces of OGRE are implemented but it is impressing what's possible with ogre4j already. We are looking forward for feedback of the experienced members of the GameDev.net community. Best regards, yavin PS: I hope to have the time to write a full article about ogre4j. Stay tuned ... [Edited by - yavin02 on August 2, 2005 5:16:52 AM]

Share this post


Link to post
Share on other sites
Advertisement
Looks very promising!

However, I have two questions for you:

1. There's a single method that relies on Java3D. You're not serious about keeping this dependency, right? =D
2. Are you planning on tying the bindings with SWT? Not really bad, but I hope you're not up to it ;)

If I werent as busy as hell with my graduation... I would certainly be interested in helping out. OGRE is my engine of choice when I toy with C++, and I've seen great games using it.

Son Of Cain

Share this post


Link to post
Share on other sites
Quote:
1. There's a single method that relies on Java3D. You're not serious about keeping this dependency, right? =D

Your're right I'm on that issue. This function is very helpful if converting geometry data from a J3D scenegraph. ... I think we will remove this function to get rid of that dependency.

Quote:
2. Are you planning on tying the bindings with SWT? Not really bad, but I hope you're not up to it ;)

No we won't do that.

Share this post


Link to post
Share on other sites
At this stage in the evolution of 3D Java... it would be more useful to have a pure Java port of OGRE rather than a JNI binding.

Cas :)

Share this post


Link to post
Share on other sites
Quote:
Original post by princec
it would be more useful to have a pure Java port of OGRE rather than a JNI binding.

What would be the advantage of a Java port, compared to the JNI bindings? IMHO porting OGRE to Java will result in another version of Java3D ;-) The speed of the native implementation will be lost ...

Share this post


Link to post
Share on other sites
What did you mean by speed of a native implementation? Exe code compiled for MMX at most, would be MUCH slower that identical program writen in Java, and used on CPU with SSE2 instruction set support.
Of course Java port would alow for better inlining, BTW I remember that my modification of JOGL was able to do 1E6 triangles on 6 year old GFX card with lighting, and shadowing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raghar
What did you mean by speed of a native implementation?

I thought that porting OGRE will loose the speed of the OGRE C++ implementation ... Maybe I'm wrong with that. I know there are benchmarks which show that Java is faster than C++ but I'm not uptodate about this issue. I'm able to remember a comparison between Java3D, OpenGL and DirectX which was evaluated by a student of my universtiy. The results were clear, Java3D was far behind OpenGL and DirectX.

Quote:
Original post by Raghar
Of course Java port would alow for better inlining, BTW I remember that my modification of JOGL was able to do 1E6 triangles on 6 year old GFX card with lighting, and shadowing.

That's cool. But you modificated JOGL and JOGL only deals with OpenGL. OGRE deals with both, DirectX and OpenGL and it provides a much more advanced API. Furthermore due to the plugin concept of OGRE it is very easy to extend OGRE with interfaces for new graphics libraries.

Share this post


Link to post
Share on other sites
The Java community tends to favour OpenGL because it's crossplatform (and simpler ;))

As for the speed - you'll most likely find that a pure Java implementation of OGRE is approximately the same speed as the C++ version if used with the server VM, or maybe 50-80% of the speed of the C++ version with the client VM.

Cas :)

Share this post


Link to post
Share on other sites
Hi,

I agree with princec on this. Perhaps you can use the bindings to backup the code that is not completely ported to Java? That would be a nice extension to the original project, the one you're showcasing now.

Son Of Cain

Share this post


Link to post
Share on other sites
Quote:
Original post by yavin02
Quote:
Original post by princec
it would be more useful to have a pure Java port of OGRE rather than a JNI binding.

What would be the advantage of a Java port, compared to the JNI bindings? IMHO porting OGRE to Java will result in another version of Java3D ;-) The speed of the native implementation will be lost ...


I agree with yavin02 here...

I see no valid reasons to port OGRE to java. A binding would take much less time to complete. I would much rather have OGRE now than wait a long time for a java port to be available (which would need constant updating to be in synch with the c++ version). A binding can be made available with relatively little work.

I would love to help out with this project. You can get in touch with me at:
earl3982@yahoo.com or just send me an instant message at earl3982 (using AIM).

Share this post


Link to post
Share on other sites
Quote:
Original post by princec
The Java community tends to favour OpenGL because it's crossplatform (and simpler ;))

OGRE is crossplatform too and you can benefit from D3D if you want. We experienced that D3Ds performance is better but this is of course no argument to linux users. Another advantage is the easy API of OGRE which wrapps OpenGL (and D3D). Of course there are some native issues, like disposing, but I think JOGL have to deal with such stuff too.

Quote:
Original post by princec
As for the speed - you'll most likely find that a pure Java implementation of OGRE is approximately the same speed as the C++ version if used with the server VM, or maybe 50-80% of the speed of the C++ version with the client VM.

I agree with earl3982 a complete port is too much and not needed.

Share this post


Link to post
Share on other sites
Quote:
Original post by yavin02
We experienced that D3Ds performance is better but...

Hey on some unkown reasons on a GeForce 6800 GO OpenGL seems to be faster then D3D. Does someone have an explanation?

Share this post


Link to post
Share on other sites
There's no technical reason why OpenGL would be faster or slower than Direct3D for any application of any kind. They both use the same paradigms, both use the same underlying code at the device driver level usually, and both use the same graphics card, of course.

Cas :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
    • By Vu Chi Thien
      Hi fellow game devs,
      First, I would like to apologize for the wall of text.
      As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha). 
      Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
      - The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
      - When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
      - There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
      speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
      Also I have a few questions:
      - In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
      - Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
      - Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?
      Please help me out with this. I haven't found any topic about this yet on gamedev, and this is my final piece of the puzzle. Thank you guys very very much.
    • By Estra
      Memory Trees is a PC game and Life+Farming simulation game. Harvest Moon and Rune Factory , the game will be quite big. I believe that this will take a long time to finish
      Looking for
      Programmer
      1 experience using Unity/C++
      2 have a portfolio of Programmer
      3 like RPG game ( Rune rune factory / zelda series / FF series )
      4 Have responsibility + Time Management
      and friendly easy working with others Programmer willing to use Skype for communication with team please E-mail me if you're interested
      Split %: Revenue share. We can discuss. Fully Funded servers and contents
      and friendly easy working with others willing to use Skype for communication with team please E-mail me if you're interested
      we can talk more detail in Estherfanworld@gmail.com Don't comment here
      Thank you so much for reading
      More about our game
      Memory Trees : forget me not

      Thank you so much for reading
      Ps.Please make sure that you have unity skill and Have responsibility + Time Management,
      because If not it will waste time not one but both of us
       

    • By RoKabium Games
      We've now started desinging the 3rd level of "Something Ate My Alien".
      This world is a gas planet, and all sorts of mayhem will be getting in our aliens way!
      #screenshotsaturday
  • Advertisement