Scientific Engine?

Hey guys,

As you're probably aware, I've left full time employment and have been working under my own company for a few months now doing software contracting.  Most of the projects I'm involved in use jME in some way.  This has worked well and kept me involved in making minor corrections to the engine, etc.  That said, I am now running into an interesting dilemma as I have a couple of projects where the customer hopes to change the engine to support greater levels of accuracy.  Specifically in terms of scene transforms, camera transforms, vertex positioning, and other such areas.

My major concern is that such changes would require jME to move to using doubles (or even Double) in many areas and in general, do calculations and hold on to more memory than would be necessary in most non-scientific type uses.  So, I am currently looking at two possibilities:

  1. Fork the engine as "jme science" or whatever and make changes directly for the engine to be mindful of accuracy over performance (vs. our current model).
  2. Try to make all such changes pluggable and generic enough so you can use jme and choose which one you care more about.

    Normally, I would say 2 would be a better choice, but it would be a lot more work to do right and probably all on my shoulders.  I'm also not sure if it would just end up being used by a small number of people and confuse the heck out of everyone else.

    I'm leaning towards the fork option, but I wanted to see what others thought.

    – Josh

Why do you want to use double precision in the scenegraph? In our science projects at university we were using double (or even BigDecimal-like stuff) in the data/calculation model but single precision floats on the view side. There is no use for floats in a scenegraph usually as the visual representation is calculated in float on the graphics card anyway. But I assume it's easier for you to avoid mapping of the values and probably you do not even have a separated data model, right?

Is it really true that it required less effort to port/adapt the scenegraph to doubled than just mapping values for visualization?

I would say if there are strong reasons why doubles would be better just do a "release" of 2.0 then make the changes directly.  Sure where easy backward compatibility is great, but the reason we moved to 2.0 was to have the flexibility to make the larger changes to the engine without people complaining.  People relying on 2.0 realize it's in a state of flux, so I say option #2 is better if there are good reasons to use double instead of float and no real disadvantages.