JavaGL : old-school, 100% software, 3D engine

WIP games, tools & toy projects
#1

800×599 7.5 KB

( just to have a picture in the showcase ::slight_smile: )

Hello,

Today I’d like to present a project I develop from time to time since several years now : JavaGL (yes, again another one !) . It’s a little library of graphical functions between the render API and the 3D engine.
Actually, firsly the application possesses a 3D software render system based on the OpenGL model and providing its main functionalities : render parameters (perspective, clipping planes, cullfacing), spatial transformations (rotation, translation, scale, pushMatrix/popMatrix), basical materials (diffuse color, shininess, wire-frame/solid faces), dynamic light, primitives display (triangles, lines, bitmap sprites), etc…
Secondly, above this are built some higher level functionalities touching numerous domains : skeletal animation, collisions/physics, file loading (OBJ and Milkshape3D ASCII), scene management, real-time game management (maps, sceneries, entities, events, pathfinding), etc…

I have to specify that the goal isn’t to compete with 3DZZD or jPCT which are fantastic engines based on an emulation of graphic chipsets. The purpose is instead to come back to an old-school 3D, like on Atari ST for example, when material acceleration or display buffers didn’t exist. So there’s a lot of lacks, like the lack of textures, but also a few advantages like allowing large screens without (too many) loss of performances.

And so I announce proudly the release of JavaGL V0.8 !

This version isn’t a revolution compared to the last one but corrects its main defaults and provides new functionalities that I learnt to implement since 1 year of Flesh Snatcher :wink: .

The improvements :

  • Timer in nanoseconds (-> JavaGL is now compatible Java 1.5 and + )
  • Correction of a bug on gravity
  • Correction of a bug on multiple collisions management
  • Correction of a bug on bounce management
  • Correction of a bug on Milkshape3D animations loading
  • Detection and correction of possible collision errors
  • Total prevention of file loading crashes
  • Duplication functions of all the data structures (from the vector to the full game map)
  • Control of “cleanness” of the BSP trees
  • Lines display optimization

The new features :

  • OBJ format support
  • Shapes intersections detection system
  • Cleaning of the invisible faces of a set of meshes
  • Procedural primitives (cube, sphere, geosphere, cylinder, cone, height-map)
  • Terrains management system (generation, display, collisions)
  • Bitmap sprites integration
  • Events management system (all events possible ingame)
  • Pathfinding in a 3D graph (Dantzig algorithm)
  • Game maps management (sceneries modifiable in real-time + entities)
  • Implementation of a simple game loop

That’s all folks ! The goal of this version is to gather the max possible functions to make a game like Tesseract in a minimum of code. As the lib manipulation can be different of “regular” engines, The accessibility is also a priority with simple functions (I hope so), and a set of demos/tutoriels integrated to explain the most disconcerting features. Finally, pedagogy is also an important aspect of the project (for me in first !), so the code is provided under GPL to allow to developers to criticize the “weirdnesses” I commit, and allow to everyone to comprehend more classical algorithms.

Thanks for your attention, and here are the traditional links :wink: :

Download :

Web site :
http://javagl.sourceforge.net/

Direct accesses to demos :
JavaGL logo
Procedural shapes
Collisions
Skeletal animation
Billboard 3D sprites
Terrain generator

As usual, don’t hesitate to post your comments :wink: .

#2

I’m excited from the demos.

#3

I hate to be the mean nasty guy who asks, but … why? Even the cheapest phone I can buy (that runs third party apps) will run OpenGL.

#4

Impressive. Still needs permission to run though. What’s the win? :slight_smile:

#5

This is really cool and all but I have the same concern as sproingie :stuck_out_tongue:

Also, why did the JavaGL logo applet need permissions?

EDIT: Seems like permissions aren’t necessary, because I declined permissions and yet it still ran…so why did you sign it? :stuck_out_tongue:

#6

@ReBirth
Hey, thank you ! I hope they make you wish to play a little with the sources :wink: .

@sproingie and ra4king
Ha ha, that’s a good question ! At the beginning it was to have a good grade in my ingeneer studies :smiley: , and I loved the idea to program graphical apps from A to Z. Then, as I added functionalities, the software renderer became a feature amongst others, the lib could be used for other reasons (for example I use it in my FPS Flesh Snatcher for math or collisions), so I continued to maintain it.
And now, with the “retro” wave that grows up, I think maybe it can be useful to someone (to make, for example, remakes of first 3D games, etc… without using heavy engines).
And finally, I must say I believe in the future of software rendering, with projects like Larrabee (infortunately abandoned) the graphic chipset will disappear and maybe the door will be opened for other kinds of 3D . Yeah, javagl accelerated by 32 dedicated CPUs, that would rock ! (Ok, I go back down…)

@Mads and ra4king
Thank you ! For the permission, yes I had to sign the jar (the same for all demos) just because of this damned class Robot I use in the “terrain generator”, grrr !

#7

I don’t really understand this whole “software rendering” craze. Hardware rendering will always be faster and better…why the need to take a step backwards into slower rendering?

#8

[quote=“N_I_C_S,post:6,topic:39237”]
FYI: the Larrabee was a graphics chipset: it had texture units, but ignoring that, I’d say: unlikely in the next decade. Dedicated hardware will always be faster (or have a more acceptable efficiency) than general purpose hardware.

Some day general purpose hardware will be ‘fast enough’ for realtime photon mapping. Let’s say performance doubles every 18 months (Moore’s Law says transistor-count doubles, but what the heck). In 10 years we’ll have 2^(10 / 1.5)=~100x the performance we have today on our CPUs, so these futuristic CPUs will still be slower than current GPUs. Needless to say GPUs will advance too, and looking at the performance growth in the last 5 years, their performance is accelerating faster than that of CPUs.

My guestimate is 50 years from now, but until then, keep writing software-rasterizers, if only because it’s so much fun :slight_smile:

#9

Actually have you heard that some researchers broke Moore’s Law?

#10

Offtopic:

Moore’s Law is about commercially-viable CPUs. I’ll take quantum computing serious when it becomes Turing Complete and can perform actual real-world tasks, as opposed to ‘we know all answers before we finished the calculations, but we’re struggling to feed it a question and selecting the answer(s) we care about’. ramble ramble

From TFA:[quote]But physicists still can’t agree on whether a quantum computer can actually be built.
[/quote]
ramble ramble

#11

Well now I’m sad :frowning:

#12

Hmm, very interesting, Riven…
Maybe the modeling of photons behaviors isn’t the only way to use general hardware. maybe we can imagine kind of compromises (improved raycasting, I don’t know)… I see that the power of GPUs is used more and more to make other operations than the classical textured triangle rendering : various shaders, GPGPU, complex illumination, etc… Maybe something new will emerge from that…

@ra4king

[quote=Riven]keep writing software-rasterizers, if only because it’s so much fun
[/quote]
Exacty ! The main reason to make that : there’s a guilty pleasure to do “as” the hardware developers from your bedroom ;D .

#13

I believe that software 3D engines do have value. While specialized graphics hardware can do great things it always misses out on unique graphics styling that takes away from many game possibilities. I expect some cheap hardware of the future will not have a 3D accelerated graphics chipset.

#14

Actually they both agree and disagree on whether quantum computers can be built, because they have and haven’t been built and we’re just waiting to see how the wave collapses :wink:

#15

[quote=tberthel]I expect some cheap hardware of the future will not have a 3D accelerated graphics chipset.
[/quote]
I agree, it would be great to play on coffee machines thanks to software libs !

@gouessej
Ha ha, Julien, I see you behind your little medals ;D ! I know we had lively debates about this lib but I thought you finally appreciated tesseract…

PS : while speaking quantic stuffs, I just learnt they found the Higgs Boson. That’s enormous !! We will finally understand gravity (and maybe confirm some parts of the superchords theory).

#16

Looks like it lacks sub-pixel accuracy…apart from that, i always appreciate some good old software rendering… ;D

Regarding the “who needs this?”-discussion: People are still using software rendering these days. I don’t know the exact reasons, but they ARE using it. If that wouldn’t be the case, i would have removed the software renderer from jPCT some time ago. Instead, i had to extend it recently because some user was missing a feature.

#17

Hi

I have always said this project is mainly useful for pedagogical purposes. If you have fun developing it, just go on but don’t expect from creating the next replacement of OpenGL. I agree with ra4king and Riven, you cannot make something faster than hardware rendering, GPUs will go on becoming faster as time goes by and they have been used in mobile phones for more than a decade through M3G and JOGL-ES (which has been integrated in JOGL 2.0). Raytracing can be done on GPUs with shaders and it is more efficient than those solutions based on software rendering even on a PS3 (25 FPS just to display a car, the floor and some buildings).

How do you want to target low end machines with software rendering? As there are fewer Celeron 700 Mhz used nowadays, the CPUs will allow you to display much things but 3DzzD has still one of the fastest software renderer, some people claimed it was a fake software renderer until its author open sourced his code under LGPL.

Some people are still using software rendering in Java because it doesn’t require signed code, it is a nice alternative to WebGL (which is particularly slow on all machines I tested) for moderately complicated scenes. However, a very few games are using it except Tesseract (whose gameplay is really nice). This game would have been slower with full 3D models. Some people don’t want to simplify their models to use software rendering, you have to face it.

Anyway, applets are being killed by Apple, Google, Mozilla and Microsoft, they just use the security concerns as an excuse whereas Silverlight, WebGL and Flash have security flaws too. Therefore, regarding the “who needs this?” discussion, I see fewer people than before because I don’t see the interest of software rendering in heavy clients as it seems easier for me to get user permissions for such applications.

I’m ill so my brain is not as efficient as usual. Good luck.

#18

[Off-topic]
I’m think 3D Software Renderer’s is good for Web(HTML5 Canvas, JavaScript) because WebGL does’t supporting in Microsoft Internet Explorer, but Java( Desktop applications, Applets ) I’m think can use OpenGL and don’t need 3D Software Renderer.
[Off-topic]

Good luck with JavaGL, Demos looks good. :slight_smile:

#19

You can use WebGL on MSIE thanks to IEWebGL and Google Chrome Frame.

#20

To jump into a thread hijack. Software scanline rendering is dead and will remain dead. amen. Moves toward less special purpose hardware rendering will occur…but that’s a different animal. (Actually this has been going on for awhile anyway)