This is what I wanted to see, though I had hoped it would have happened earlier...
that maybe we were missing something or that the future of Ogre isn't all doom and gloom.
Rumors?
-
psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Rumors?
scrawl wrote:Rendering 100 copies of this tree
That's what I missed.scrawl wrote:- As mentioned it is rendering 100 copies of the same model, not one model.
Thanks!
Re: Rumors?
New interesting post by Scrawl about OSG and Ogre3D comparison. Looking forward to the OSG port. 
http://scrawl.bplaced.net/blog/?p=227
http://scrawl.bplaced.net/blog/?p=227
Re: Rumors?
Br0ken wrote:http://scrawl.bplaced.net/blog/?p=227
This is why I get up in the morning. Amazing work.scrawl wrote:https://www.youtube.com/watch?v=0mctgvaCUH8
Re: Rumors?
Very nice, seems like you're making good progress.
Re: Rumors?
Particles are working now. There are a few things I really like in OSG's particle system, overall the code is turning out much cleaner than the old one.
The good:
- There is actually a separation between Emitter nodes and Particle nodes, matching what NIFs expect. Moving an emitter node causes the emit position for new particles to change. Moving the particle node around causes the position of already emitted particles to change. In Ogre, only the latter statement was true, the first had to be hacked in our code.
- Custom emitters and affectors can be created directly instead of going through a factory system and having to pass parameters through a string interface or UserData.
The ugly:
- Particles are set up with a (customizable) Interpolator class to handle changes to size, color and alpha. The only input to this interpolator is the minimum value, maximum value and normalized particle age. Not flexible enough for NIFs, which are using keyframes among others, having the normalized age doesn't help, because the lifetime of a particle is random. I would much prefer if this was handled by the affectors (Programs) instead. That is actually what I ended up doing, but instead of saying "set this particle's size to this value" I have to say "set this particle's minimum size and maximum size to this value". Works fine, but not so elegant.
- Multiple virtual function calls per particle per frame (the interpolators in particular).
- Most of the logic is using doubles, which seems unnecessary. I also noticed this elsewhere in osg, for example the transform matrices. But those are toggleable in cmake at least, so we'd probably use single precision in our official release builds.
All in all, much nicer to work with than the Ogre particle system. Some room for performance improvement, but likely insignificant enough that it's not worth spending any time on it.
The good:
- There is actually a separation between Emitter nodes and Particle nodes, matching what NIFs expect. Moving an emitter node causes the emit position for new particles to change. Moving the particle node around causes the position of already emitted particles to change. In Ogre, only the latter statement was true, the first had to be hacked in our code.
- Custom emitters and affectors can be created directly instead of going through a factory system and having to pass parameters through a string interface or UserData.
The ugly:
- Particles are set up with a (customizable) Interpolator class to handle changes to size, color and alpha. The only input to this interpolator is the minimum value, maximum value and normalized particle age. Not flexible enough for NIFs, which are using keyframes among others, having the normalized age doesn't help, because the lifetime of a particle is random. I would much prefer if this was handled by the affectors (Programs) instead. That is actually what I ended up doing, but instead of saying "set this particle's size to this value" I have to say "set this particle's minimum size and maximum size to this value". Works fine, but not so elegant.
- Multiple virtual function calls per particle per frame (the interpolators in particular).
- Most of the logic is using doubles, which seems unnecessary. I also noticed this elsewhere in osg, for example the transform matrices. But those are toggleable in cmake at least, so we'd probably use single precision in our official release builds.
All in all, much nicer to work with than the Ogre particle system. Some room for performance improvement, but likely insignificant enough that it's not worth spending any time on it.
Re: Rumors?
@scrawl
Thanks for the update! It's always fun to read what you're working on, regardless if you have anything to show or not. It would be fun if you were able to find a couple of mins to do (small) updates more regularly, since your work is so highly anticipated. No pressure though.
Thanks for the update! It's always fun to read what you're working on, regardless if you have anything to show or not. It would be fun if you were able to find a couple of mins to do (small) updates more regularly, since your work is so highly anticipated. No pressure though.
Re: Rumors?
Figured I might as well get OpenCS up and running, so that I have a nicer testing setup for developing the NIF loader (and later on, terrain). Cell rendering isn't ported yet, but I have the preview window rendering using OSG, and the resources table using the new VFS.
http://scrawl.bplaced.net/temp/screen00-12-39.png
http://scrawl.bplaced.net/temp/screen00-33-45.png
The second screenshot shows off antialiasing, which never worked on Linux with the Ogre-Qt (nor with the Ogre-SDL) integrations we were using. The new code is based on the osgviewerQt from the OSG examples, which is basically using a QGLWidget.
Having multiple scene widgets at the same time works fine, though there seems to be a bug with vsync; each widget will refresh to (refresh rate/num scene widgets) instead of the usual refresh rate. Looks like a bug in QGLWidget. Well, we're not going to need vsync anyway, the viewport is only refreshed when the camera moves or the content changes.
http://scrawl.bplaced.net/temp/screen00-12-39.png
http://scrawl.bplaced.net/temp/screen00-33-45.png
The second screenshot shows off antialiasing, which never worked on Linux with the Ogre-Qt (nor with the Ogre-SDL) integrations we were using. The new code is based on the osgviewerQt from the OSG examples, which is basically using a QGLWidget.
Having multiple scene widgets at the same time works fine, though there seems to be a bug with vsync; each widget will refresh to (refresh rate/num scene widgets) instead of the usual refresh rate. Looks like a bug in QGLWidget. Well, we're not going to need vsync anyway, the viewport is only refreshed when the camera moves or the content changes.