OpenGEX as .Nif alternative for OpenMW

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
Lamoot
Posts: 52
Joined: 22 Apr 2016, 12:03

Re: OpenGEX as .Nif alternative for OpenMW

Post by Lamoot » 03 Sep 2017, 12:41

scrawl wrote:
02 Sep 2017, 10:10
Another issue is providing a separate collision mesh. We could use a separate file for that or use tags in the visual file to denote a mesh as a collision mesh. Aside from collision meshes it would be nice to support shapes (e.g. MultiSphereShape) because they're much faster to process than triangle meshes. I believe bullet's btWorldImporter has a file format but I haven't really looked into how usable it is.
Workflow-wise, it sounds simpler creating and defining the visual-collision mesh pair in 3d app compared to exporting them separately and combining afterwards. And it avoids doubling the number of files for mesh assets, which a project can have a lot (as seen already in that editor thread).

Blender uses Bullet physics as well, and meshes with physics settings could be taken into account at export and tagged for collision. On the editor end, preview of the asset with its collision is then all that's needed.
blender_collision_options.png

crassell
Posts: 46
Joined: 26 Aug 2017, 21:10
Github profile: https://github.com/crussell187

Re: OpenGEX as .Nif alternative for OpenMW

Post by crassell » 23 Sep 2017, 17:45

Trying not to spawn another thread I'm going to take up the osgt/osgb importer/export support for animations before finishing my generic elder scrolls / fallout nif parser. When you say the below:
scrawl wrote:
02 Sep 2017, 10:10
- Move KeyframeController out of nifosg into a component (e.g. sceneutil) and make it not depend on NifOsg::NodeUserData
- Add support for other types of keyframes as needed
- Move TextKeyMap out of nifosg into a component
Did you want KeyframeController in it's own component (something like keyframe) and TextKeyMap in an entirely different component (textkey)? Or do we just want to create an animation component to house all of these files?
scrawl wrote:
02 Sep 2017, 10:10
Another issue is providing a separate collision mesh. We could use a separate file for that or use tags in the visual file to denote a mesh as a collision mesh. Aside from collision meshes it would be nice to support shapes (e.g. MultiSphereShape) because they're much faster to process than triangle meshes. I believe bullet's btWorldImporter has a file format but I haven't really looked into how usable it is.
I think I'm going to try to factor the collision mesh into the format.

User avatar
scrawl
Posts: 2049
Joined: 18 Feb 2012, 11:51
Contact:

Re: OpenGEX as .Nif alternative for OpenMW

Post by scrawl » 23 Sep 2017, 18:24

Yay :D I assume you're aware of the discussion in the other thread where the consensus was to try importing osgAnimations into our animation system, rather than extending the osg format with our own animation classes.
Did you want KeyframeController in it's own component (something like keyframe) and TextKeyMap in an entirely different component (textkey)? Or do we just want to create an animation component to house all of these files?
KeyframeController and TextKeyMap should probably go in the same component. They don't depend on one another, but are meant to be used together. I think the answer is either a new 'animation' component that houses everything (including classes like RigGeometry, Skeleton and MorphGeometry that are currently under sceneutil), or stuff the new animation classes under sceneutil/ along with the rest. I'd probably go with the latter because there are some other (not entirely animation related) files under sceneutil that use (or depend on) the animation classes, and cross-component dependencies are best avoided.
I think I'm going to try to factor the collision mesh into the format.
Right. We could use the UserDataContainer (e.g. a 'collision' description string on the node), or maybe use nodes with a certain name as collision. Ideally we'd want to be able to set this directly from Blender.

crassell
Posts: 46
Joined: 26 Aug 2017, 21:10
Github profile: https://github.com/crussell187

Re: OpenGEX as .Nif alternative for OpenMW

Post by crassell » 23 Sep 2017, 18:45

scrawl wrote:
23 Sep 2017, 18:24
Yay I assume you're aware of the discussion in the other thread where the consensus was to try importing osgAnimations into our animation system, rather than extending the osg format with our own animation classes.
These are the steps I'm thinking about taking so far:
1. take some trivially simple static object, give it 1 or 2 bones and have it rotate. I want to export it from blender with the default osgt and osgb format and see about re-interpreting it to work with our classes.
2. I'll move on to the more complicated animations that are already in nif, export them from openmw to osgt/osgb using the same modifications I used to import in step 1, make a modification in blender, and then run them in openmw directly from osgt/osgb.

I'm hoping step 1 irons out a lot of the basic problems to make step 2 easier.
scrawl wrote:
23 Sep 2017, 18:24
KeyframeController and TextKeyMap should probably go in the same component. They don't depend on one another, but are meant to be used together. I think the answer is either a new 'animation' component that houses everything (including classes like RigGeometry, Skeleton and MorphGeometry that are currently under sceneutil), or stuff the new animation classes under sceneutil/ along with the rest. I'd probably go with the latter because there are some other (not entirely animation related) files under sceneutil that use (or depend on) the animation classes, and cross-component dependencies are best avoided.
sceneutil it is then. After some components get quite large, should we think about creating sub-components :) ? Either that or a simple naming scheme like prepending animation files with anim would do.
scrawl wrote:
23 Sep 2017, 18:24
Right. We could use the UserDataContainer (e.g. a 'collision' description string on the node), or maybe use nodes with a certain name as collision. Ideally we'd want to be able to set this directly from Blender.
This will be step 3 :)
3. Study the UserDataContainer option for osg and incorporate it into Blender with the necessary blender importer/exporter modifications.

I'm chosing to focus on blender because I don't have / can't afford the proprietary modelling tools and I figure focusing on the open source option first is best.

Chris
Posts: 1274
Joined: 04 Sep 2011, 08:33

Re: OpenGEX as .Nif alternative for OpenMW

Post by Chris » 23 Sep 2017, 19:21

crassell wrote:
23 Sep 2017, 18:45
3. Study the UserDataContainer option for osg and incorporate it into Blender with the necessary blender importer/exporter modifications.
I'd be surprised if this wasn't already possible. "Tagging" specific nodes with text metadata is a pretty basic thing for node-based formats. Requiring custom importers and exporters is not a good solution because it then relies on using modelling software that can use our specific importers and exporters (it's also then extra things we need to maintain if we want people to be able make models with alternative formats). How annoying would it be if we supported PNG for textures, but relied on a custom importer/exporter plugin because it required custom fields that aren't normally there, and that plugin only worked in GIMP. The purpose of being able to support osgt/osgb (and specific other formats through OSG's plugins) is that they'll Just Work with preexisting modelling programs that generated the files, be it 3DSMax, Maya, Blender, or whatever else comes out in the future.

crassell
Posts: 46
Joined: 26 Aug 2017, 21:10
Github profile: https://github.com/crussell187

Re: OpenGEX as .Nif alternative for OpenMW

Post by crassell » 23 Sep 2017, 23:36

I think I'm just showing my ignorance on how blender would be configured to append this collision metadata in the existing osg format export for animation files. I still have to study the format to know if the animation format is mesh plus bone transformation data or is the mesh in a different file :D . I'm still a graphics programming newb so I'm sure there will be several iterations of this once I get started.

User avatar
psi29a
Posts: 3394
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: OpenGEX as .Nif alternative for OpenMW

Post by psi29a » 24 Sep 2017, 11:22

I really like where this thread is going... :D

User avatar
lysol
Posts: 675
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: OpenGEX as .Nif alternative for OpenMW

Post by lysol » 24 Sep 2017, 12:47

psi29a wrote:
24 Sep 2017, 11:22
I really like where this thread is going... :D
There has been quite a few of those threads lately. :)
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
AnyOldName3
Posts: 454
Joined: 26 Nov 2015, 03:25

Re: OpenGEX as .Nif alternative for OpenMW

Post by AnyOldName3 » 24 Sep 2017, 13:11

The 0.42 release probably attracted a bunch of new talent.

crassell
Posts: 46
Joined: 26 Aug 2017, 21:10
Github profile: https://github.com/crussell187

Re: OpenGEX as .Nif alternative for OpenMW

Post by crassell » 25 Sep 2017, 04:34

Looks like more than just TextKeyMap needs to be abstracted away from the nif:

typedef ValueInterpolator<Nif::QuaternionKeyMap, QuaternionSlerpFunc> QuaternionInterpolator;
typedef ValueInterpolator<Nif::FloatKeyMap, LerpFunc> FloatInterpolator;
typedef ValueInterpolator<Nif::Vector3KeyMap, LerpFunc> Vec3Interpolator;

Here's the dependency unravelling so far:
KeyframeController -> ValueInterpolator -> Nif::*KeyMap

I'm assuming since we want to maintain compatibility with the osgb/osgt format serialization for the default osg animation, directly replacing these nif key maps with osg serializers will not be sufficient.

I'm going to try to make an excel representing the hierarchy of the 2 formats before I continue with code and back myself into a corner.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests