Revisiting the idea of FO3/Oblivion support

[sjek]

what have understood collada and opengex are both text based formats, custom loader to convert them into binary on runtime would anyway be needed.
collada is xml and not really human readable so possibly external library would be used and opengex has import template and their format possibly making conversion easier.

problem comes when blender and other support is wanted, their's api not being the most open ones so it's partly reverse engineering which effect goes where.

if it's known inside openmw which part of code goes where, it could be easier to convert in between them instead of dealing with multiple 3D programs.

edit: maybe something like optimising underplaying load structure what have been done more or less.
when there's extra features outside nif the format can be extended or read from other loaders/formats. ......

what is the best way to read them into program and how dependant the loading style is from format ie. is the nif converted any way in the progress and, is what is used convertible between text and binary in which case, depending if separate conversion is used it could be patched with features from opengex and collada at will and add where architecture says?
at the long road

basically stripping the undocumented parts away and straightening bugs/design laws

[psi29a]

blender is open-source, no reverse engineering necessary... read the documentation and/or source.

NIF is the problem, proprietary format totally undocumented full of reverse engineering.

[sjek]

seems like it. read somewhere time ago that there's no documented correlation with export functions and the effects applied in the blender which is true (or seems like with quick lookout, depending what object i actually points to) and with nif the problem is basically that as blender gives bare file info with numbers to handle. for what all attributes and write functions has to be defined inside the script. ( which i think makes 2.49 nif export buggy)

in the opengex expoter for example.

first after imports and defining variables
it defines class ExportVertex which seems to define conditions to write and address

then class OpenGexExporter(bpy.types.Operator, ExportHelper):
is defined with bpy maybe definition and helper class

and continues on defining write (self, text) and indentwrite (self, text, extra = 0, newline = False)
function and others guickly going to numerical algorithms and if / for clauses on what to write

Code: Select all

def Write(self, text):
		self.file.write(text)


	def IndentWrite(self, text, extra = 0, newline = False):
		if (newline):
			self.file.write(B"\n")
		for i in range(self.indentLevel + extra):
			self.file.write(B"\t")
		self.file.write(text)


	def WriteInt(self, i):
		self.file.write(bytes(str(i), "UTF-8"))


	def WriteFloat(self, f):
		if ((math.isinf(f)) or (math.isnan(f))):
			self.file.write(B"0.0")
		else:
			self.file.write(bytes(str(f), "UTF-8"))


	def WriteMatrix(self, matrix):
		self.IndentWrite(B"{", 1)
		self.WriteFloat(matrix[0][0])
		self.Write(B", ")
		self.WriteFloat(matrix[1][0])
		self.Write(B", ")
		self.WriteFloat(matrix[2][0])
		self.Write(B", ")
		self.WriteFloat(matrix[3][0])
		self.Write(B",\n")

Spoiler: Show

def ExportNodeTransform(self, node, scene):
---posAnimCurve = [None, None, None]
---rotAnimCurve = [None, None, None]
---sclAnimCurve = [None, None, None]
---posAnimKind = [0, 0, 0]
---rotAnimKind = [0, 0, 0]
---sclAnimKind = [0, 0, 0]

---deltaPosAnimCurve = [None, None, None]
---deltaRotAnimCurve = [None, None, None]
---deltaSclAnimCurve = [None, None, None]
---deltaPosAnimKind = [0, 0, 0]
---deltaRotAnimKind = [0, 0, 0]
---deltaSclAnimKind = [0, 0, 0]

---positionAnimated = False
---rotationAnimated = False
---scaleAnimated = False
---posAnimated = [False, False, False]
---rotAnimated = [False, False, False]
---sclAnimated = [False, False, False]

---deltaPositionAnimated = False
---deltaRotationAnimated = False
---deltaScaleAnimated = False
---deltaPosAnimated = [False, False, False]
---deltaRotAnimated = [False, False, False]
---deltaSclAnimated = [False, False, False]

---mode = node.rotation_mode
---sampledAnimation = ((self.sampleAnimationFlag) or (mode == "QUATERNION") or (mode == "AXIS_ANGLE"))

---if ((not sampledAnimation) and (node.animation_data)):
------action = node.animation_data.action
------if (action):
---------for fcurve in action.fcurves:
------------kind = OpenGexExporter.ClassifyAnimationCurve(fcurve)
------------if (kind != kAnimationSampled):
---------------if (fcurve.data_path == "location"):
------------------for i in range(3):
---------------------if ((fcurve.array_index == i) and (not posAnimCurve)):
------------------------posAnimCurve = fcurve
------------------------posAnimKind = kind
------------------------if (OpenGexExporter.AnimationPresent(fcurve, kind)):
---------------------------posAnimated = True
---------------elif (fcurve.data_path == "delta_location"):
------------------for i in range(3):
---------------------if ((fcurve.array_index == i) and (not deltaPosAnimCurve)):
------------------------deltaPosAnimCurve = fcurve
------------------------deltaPosAnimKind = kind
------------------------if (OpenGexExporter.AnimationPresent(fcurve, kind)):
---------------------------deltaPosAnimated = True

etc.

depending how big change there has been with bmesh and numerical file format it's basically guesswork writing it to bytes and checking ingame. in openmw they are read as values set in code so writing corresponding file could be much easier.
or modify after 1.0 both where needed if hex key aren't exact method of saving (don't know, would possibly require header change and duplicating code)

and more specifically from 2.5.5 blender nif script

Code: Select all

if (ob.data.envelopes):
                        self.logger.critical(
                            "'%s': Cannot export envelope skinning."
                            " If you have vertex groups,"
                            " turn off envelopes. If you don't have vertex"
                            " groups, select the bones one by one press W"
                            " to convert their envelopes to vertex weights,"
                            " and turn off envelopes."
                            % ob.getName())
                        raise NifExportError(
                            "'%s': Cannot export envelope skinning."
                            " Check console for instructions."
                            % ob.getName())

they are dealing with buggy engine

should try to turn of and write some export. don't know why else they would place this + material texture limitation other that possibly nif / blender architecture. it makes exporting anything out of ordinary pain in the **

[Greywander]

I suppose I might as well ask here, since it's been bugging me for a while. But why does OpenMW only support NIFs? I'll admit I don't understand how all the backend software works, but I'm a little confused why OpenMW doesn't support a wider variety of 3D model formats out of the box. I would have thought something like this would have come standard with OSG, and OGRE before it, although to be honest I don't fully understand what those do except that they have something to do with graphics. How difficult would it be to add support for a wider variety of 3D models?

I assume this is on the to-do list, probably post-1.0. But for now, making new models for OpenMW requires jumping through some hoops, and it would be easier to develop original assets for, say, an example suite if there was better support for more popular/common 3D models.

[Chris]

I suppose I might as well ask here, since it's been bugging me for a while. But why does OpenMW only support NIFs? I'll admit I don't understand how all the backend software works, but I'm a little confused why OpenMW doesn't support a wider variety of 3D model formats out of the box.

It will eventually, but certain NIFs contain information the engine needs (text keys that specify where certain animations start/stop, when something should happen during an animation, if it should automatically play its animation, etc). Assumptions had to be made about how the models are composed and what information they provide to make them work in the engine as intended, so other formats will need similar considerations.

Unfortunately models aren't like images or sounds, where all you need to do is decode it to a raw RGB/PCM standard. Every model format is different, and is tailored to different engines. There is no standard for raw model data, though even if there was it'd be so basic and limited that a lot of useful information would be missing.