XNALara Help & Resources

[TheLostSecret]

Originally Posted by Cochrane

Short story: This is not important. I'm just making jokes.

Long story: I'm the author of GLLara, a tool that is like XNALara, but for Macs. I'm currently fixing a number of things there. When I saw you were having trouble, I decided to look at the models myself and see how GLLara worked with them. Turns out I had a few bugs in there that I didn't notice before.

In particular:
- I had some issues with the user interface not showing up correctly
- Some changes I made lately caused all OBJ files to be invisible when loading

And then there's the thing where some textures are weird in those models, but I had already fixed that a while back.

If you're using Windows then none of this is relevant to you. I just found it interesting that I could find and fix bugs in my code this way.

(Note for non-Mac developers reading this: The giant diff for the UI stuff just means that Apple changed an internal file format for UI layouts. I hope this means future diffs will get smaller, at least until Apple changes this format the next time…)

Glad I've helped someone . Please keep up with the work and best wishes for your project .

[XNAaraL]

Originally Posted by Cochrane

Short story: This is not important. I'm just making jokes.

Long story: I'm the author of GLLara, a tool that is like XNALara, but for Macs. I'm currently fixing a number of things there. When I saw you were having trouble, I decided to look at the models myself and see how GLLara worked with them. Turns out I had a few bugs in there that I didn't notice before.

In particular:
- I had some issues with the user interface not showing up correctly
- Some changes I made lately caused all OBJ files to be invisible when loading

And then there's the thing where some textures are weird in those models, but I had already fixed that a while back.

If you're using Windows then none of this is relevant to you. I just found it interesting that I could find and fix bugs in my code this way.

(Note for non-Mac developers reading this: The giant diff for the UI stuff just means that Apple changed an internal file format for UI layouts. I hope this means future diffs will get smaller, at least until Apple changes this format the next time…)

It's not a BUG in your program at all. it's a BUG of the model(s). The model(s) ignores the XNALara requirements and it ignores the Microsoft XNA mesh requirements and it ignores the Generic_Item.mesh file specs.
(In this particular issue, Sean has used the wrong Ascii2Bin converter to get the Generic file; he used MeshAsciiToBin and not GeMeshAsciiToBin )

To make your app stable (prevent a crash with such models) is a good idea.
To try to repair every wrong model when try to load it, is in my opinion not a good idea (I know, my XPS try to do this, but this was a wrong design decision by myself).
My suggestion is, to make it like Dusan the XNALara creator have done.

This is the original XNALara v9.7.8 error message which appears if you try to load this particular model.

If you're trying to make each model loadable, which ignores the specification, then you'll have to deal with models that use a Winword document as texture, an animated GIF, renamed JPEG images (not converted) from .JPG to .PNG ...
I can point you to such uploads
And more importantly, you will have to deal with rude porters who request you to fix your app to makes there ports loadable. Some of this porters makes this corrupt files even willful and with intention wrong and claims your app would be buggy. I can point you to such comments One of this issues was one of the reason WHY I have stopped to continue to develop XPS.
A "Mostly Harmless" version of such comments, you can read in this TRF forum:

Originally Posted by Dusan

Your post isn't helpful. You didn't tell me what version on the program you have, what you did before this error appeared, which models you used etc. etc. etc.

I don't know of any bugs in my program. It is being used by hundreds of people (maybe even more) without problems.
If you have an old computer and/or old graphics card, then there is nothing I can do about it.

It's also possible you need to update your graphics card drivers.

Finally

Originally Posted by TheLostSecret

Now help me !
...

This particular model by Sean, can TheLostSecret fix quickly with XPS:

1. Load the .mesh.ascii file
2. Confirm "Should XPS fix the model" with "Yes"
3. Save it as xps.xps
4. Load the fixed model

[Cochrane]

Well, those actually were bugs in my program, I just hadn't tested OBJ export and import in a while.

My issue is that I basically have to support every model that can be loaded into XPS, no matter how unusual it might be. The thing is that my users aren't the people who port the things; the only thing my users do is download really horrible models, all day, every day, until they find one that doesn't work. I think. AT least "this model doesn't work" is usually the only thing I hear from any users. Though sometimes they even tell me which one!

I actually do support JPEG images that are renamed to .PNG, and I think also animated GIFs (but only the first frame) and so on, because the framework features in OS X make this really easy. No support for Word or PDF though, maybe I should add that.

[NGCHunter2]

This concerns only the XNALara to Blender import add-on:
I'm trying to import an .ascii model into Blender (one of the environment meshes) via the latest Blender 2.79 version of the XNALara to Blender add-on, and because the usual .obj import ignores secondary UV maps as well as Vertex colors, I would really like to import via .ascii only.

For some reason though, slightly larger .ascii files tend to make the importer prompt an error traceback message which pretty much always looks like this:
https://drive.google.com/open?id=1KE...mRhUpSi7z_pWLW
[for example: I tried importing files from 'Tomb Raider: Underworld' file folder 7FD9706D_0_233F and 9444BC19_0_238D which didn't work, while files from folder DAD54B33_0_2066 or E429C76E_0_23F8 worked perfectly.]
Do you have any idea what I can do to make the importer work on these files?


This concerns XNALara in general:
Looking at the XNALara data, I saw that Normal Maps are provided with each model (except models that don't have them in the game files as well).
Unpacking 'Tomb Raider: Underworld's game files, I stumbled upon .dds textures which seem to be Normal Maps in some kind, yet they are all yellowish/green with an alpha channel on it. I tried to invert the color and/or underlay white/black colors to make it appear close to a Normal Map, but didn't succeed. Searching for this online wasn't succesful, for I wasn't even able to find this very kind of yellowish/green map.
I put a comparison table below (note that every try with yellowish/green maps results in a heavy middle seam and sometimes noticeable flat-shaded geometry, while the XNALara Normal Map is perfectly fine):
https://drive.google.com/open?id=1M2...OYoDZvcInDnwCF
Is there a wa on how to convert the yellowish/green maps into actual, usual Normal Maps that you are aware of? And if not, how did you manage to get the perfectly fine Normal Maps out of the game?

If you would be able to answer one or both of my questions, I would be really happy about it! I apologize for my request, for I'm quite decent at modeling, but have no clue about add-on coding (and the obvious weird texture thing).

[XNAaraL]

Originally Posted by NGCHunter2

This concerns only the XNALara to Blender import add-on:
I'm trying to import an .ascii model into Blender (one of the environment meshes) via the latest Blender 2.79 version of the XNALara to Blender add-on, and because the usual .obj import ignores secondary UV maps as well as Vertex colors, I would really like to import via .ascii only.

For some reason though, slightly larger .ascii files tend to make the importer prompt an error traceback message which pretty much always looks like this:
https://drive.google.com/open?id=1KE...mRhUpSi7z_pWLW
[for example: I tried importing files from 'Tomb Raider: Underworld' file folder 7FD9706D_0_233F and 9444BC19_0_238D which didn't work, while files from folder DAD54B33_0_2066 or E429C76E_0_23F8 worked perfectly.]
Do you have any idea what I can do to make the importer work on these files?


This concerns XNALara in general:
Looking at the XNALara data, I saw that Normal Maps are provided with each model (except models that don't have them in the game files as well).
Unpacking 'Tomb Raider: Underworld's game files, I stumbled upon .dds textures which seem to be Normal Maps in some kind, yet they are all yellowish/green with an alpha channel on it. I tried to invert the color and/or underlay white/black colors to make it appear close to a Normal Map, but didn't succeed. Searching for this online wasn't succesful, for I wasn't even able to find this very kind of yellowish/green map.
I put a comparison table below (note that every try with yellowish/green maps results in a heavy middle seam and sometimes noticeable flat-shaded geometry, while the XNALara Normal Map is perfectly fine):
https://drive.google.com/open?id=1M2...OYoDZvcInDnwCF
Is there a wa on how to convert the yellowish/green maps into actual, usual Normal Maps that you are aware of? And if not, how did you manage to get the perfectly fine Normal Maps out of the game?

If you would be able to answer one or both of my questions, I would be really happy about it! I apologize for my request, for I'm quite decent at modeling, but have no clue about add-on coding (and the obvious weird texture thing).

--> http://lmgtfy.com/?q=tangent+space+n...le+coordinates <--

2) How to convert green bump maps to blue ones. (Writen by Dusan himself))
https://www.tombraiderforums.com/sho...&postcount=826

However, I do not recommend to fill BLUE channel with white color !
(The XNALara Normal Map is NEVER EVER perfectly fine)

For Dusan's XNALara, it do not matter how the Normal map looks, because XNALara do not support Normal mapping.

A Normal map is not just flat 2D RGB image. The RGB color channels (red, green, and blue) in a normal map correspond to the respective X, Y, and Z coordinates of surface normals.
You could calculate the Z coordinate (blue) back from the red and green channel (After the coordinate expansion to the -1..1 range) the blue z component can be computed with this formula: z = sqrt(1 - x*x + y*y).
There are some apps for do that.

BTW:
I never convert the Normal Maps. I just set the right swizzle coordinates:
XPS: https://www.tombraiderforums.com/sho...postcount=2999
Blender: Map the map to the low-poly model using a common coordinate system. When using a Normal map, map the texture to Normal. The coordinate systems of the two objects must match!

https://blender.stackexchange.com/qu...al-map-texture
Normal Map Technical Details - polycount - Common Swizzle Coordinates

https://www.nvidia.com/object/real-t...mpression.html

Notes: https://blender.stackexchange.com/qu...al-map-texture
"Interestingly, Blender Doc:2.4/Bump_and_Normal suggests that Blender uses the full range of the blue channel for the range of 0.0 to 1.0"
the same for Blender 2.8: https://docs.blender.org/manual/nb/d...mp_normal.html

Originally Posted by Blender 2.8 Doc

Normal maps
These are images that store a direction, the direction of normals directly in the RGB values of an image. They are much more accurate, as rather than only simulating the pixel being away from the face along a line, they can simulate that pixel being moved at any direction, in an arbitrary way. The drawbacks to normal maps are that unlike bump maps, which can easily be painted by hand, normal maps usually have to be generated in some way, often from higher resolution geometry than the geometry you are applying the map to.

Normal maps in Blender store a normal as follows:

Red maps from (0 - 255) to X (-1.0 - 1.0)
Green maps from (0 - 255) to Y (-1.0 - 1.0)
Blue maps from (0 - 255) to Z (0.0 - 1.0)
Since normals all point towards a viewer, negative Z values are not stored (they would be invisible anyway). In Blender we store a full blue range, although some other implementations also map blue colors (128 - 255) to (0.0 - 1.0).

[NGCHunter2]

Originally Posted by XNAaraL

--> http://lmgtfy.com/?q=tangent+space+n...le+coordinates <--

Originally Posted by NGCHunter2

Searching for this online wasn't succesful, for I wasn't even able to find this very kind of yellowish/green map.

Thanks for the workflow! As I said, I wasn't succesful searching for it, mostly because I had no idea how to name my search; "yellowish/green normal map" was obviously not the best term to search for "Normal Map channel switches", but I had no idea what I should search for.
Thanks again very much!

For my .ascii import problem: As I said, I can't code at all and never did (horray, a newbie!), but I tried to use some common sense on my error traceback:
• The very first error produced says "list index out of range" for the Z position of the imported mesh (for the 'read_ascii_xps.py' file). I don't know it for sure, but maybe the model itself is too large or out of a limited scene range (Underworld's environment models are always NOT centered, but off-centered to their ingame location which makes them compatible with other environment files without having them to reposition), yet I have no idea how to "fix" this issue on those files. I think two of the other errors might build up on this, for module 'readXYZ(file)' and 'readMeshes' produce errors after that as well.
• The importer seems to be unable to read the imported file's mesh names; several errors are linked to module 'readXpsModel(filename)', building up to 'loadXpsFile(xpsSettings.filename)','import_xnalar a_model.getInputFilename(xpsSettings)' and 'xpsImport()'. Again, I'm not sure how to prevent this to be honest.

If there happens to be a experienced coder who knows what might be the solution to my problem, I'm grateful (again) for any advice! And I apologize for my ignorance and possible annoyance caused by this beforehand.

[XNAaraL]

Originally Posted by NGCHunter2

...

For my .ascii import problem: As I said, I can't code at all and never did (horray, a newbie!), but I tried to use some common sense on my error traceback:
• The very first error produced says "list index out of range" for the Z position of the imported mesh (for the 'read_ascii_xps.py' file). I don't know it for sure, but maybe the model itself is too large or out of a limited scene range (Underworld's environment models are always NOT centered, but off-centered to their ingame location which makes them compatible with other environment files without having them to reposition), yet I have no idea how to "fix" this issue on those files. I think two of the other errors might build up on this, for module 'readXYZ(file)' and 'readMeshes' produce errors after that as well.
• The importer seems to be unable to read the imported file's mesh names; several errors are linked to module 'readXpsModel(filename)', building up to 'loadXpsFile(xpsSettings.filename)','import_xnalar a_model.getInputFilename(xpsSettings)' and 'xpsImport()'. Again, I'm not sure how to prevent this to be honest.

If there happens to be a experienced coder who knows what might be the solution to my problem, I'm grateful (again) for any advice! And I apologize for my ignorance and possible annoyance caused by this beforehand.

I guess you use the Python importer (XPS Tool) written by johnzero7. So you should ask him. Be aware that he can also not help you, if you do not send him one of the faulty .mesh.ascii files! And he will need the version number of the used XPS tool. And he will need the version number of your Python
Read more

About the error message(s), you interpret the error message incorrectly.
It is a "Stack Trace" and show only one error (and his call history).
So the error is just the first line(s).

Python: IndexError: list index out of range
" ... read_ascii_xps.py", line 29, in readXYZ

The rest is just the call hierarchy inside the program.
so funcion
readXYZ(file) is invoked by readMeshes(file, hasBones)
readMeshes(file, hasBones) is invoked by readXpsModel(filename)
readXpsModel(filename) is invoked by loadXpsFile()
loadXpsFile() is invoked by xpsImport()
xpsImport() is invoked by getImputFilename()

How to interpret the error:
line 29 of read_ascii_xps.py is

z = (ascii_ops.getFloat(values[2])) # Z pos

So, the importer could read "X pos" and "Y pos", but not the Z position of the vertex data.
The vertex position in .mesh.ascii must have 3 floating-point values, separated by a blank.
"IndexError: list index out of range" by getFloat(values[2]) say, that this tuple has not a index [2] (The third value is missing. Counting starts at offset 0!)
Line 25

line = ascii_ops.readline(file)

read the line of the .mesh.ascii file. Nothing wrong here.
Line 26

values = ascii_ops.splitValues(line)

split the text in (3) values. The code is in line 54 of ascii_ops.py:

def splitValues(line):
line = line.replace('#', ' ')
values = line.split()
return values

That (splitValues) is the BUG of the importer. If the line has just 2 values, then splitValues(line) return a array (list) with just 2 data values (range from index '0' to index '1')
Also, if line 29 of read_ascii_xps.py try to resolve values[2] (index '2'), this produce a "IndexError: list index out of range".

That's all.
Perhaps your .mesh.ascii file is corrupt. I have already asked you the "key question" here "How did you extract the TRU data ? (with which program)". Maybe, the right thread (to ask) can be this one ?

Blender 2.7x requires Python 3.x.
In Python 3.x a integer maximum is unlimited (Not so in Python 2.x!)
The size of the model should therefore make no difference in Python version 3. Since Python 3.0 there is no longer a limit to the value of integers.

Again:

• Without having the faulty .mesh.ascii files
• Without having the version number of the used XPS tool.
• Without having the version number o your Python interpreter

no way to help you to solve your problem.
Read more
Especially:
Before You ask
When You ask
Be precise and informative about your problem
Be explicit about your question

Don't rush to claim that you have found a bug -- unless you are very, very sure of your ground. Giving hackers the ability to reproduce the problem in a controlled environment is especially important if you are reporting something you think is a bug in code. Simon Tatham has written an excellent essay entitled How to Report Bugs Effectively. I strongly recommend that you read it.
Describe the problem's symptoms, not your guesses


Follow up with a brief note on the solution
Now RTFM

[dougdude10]

I am not attempting to spam, hopefully this question is in the right place.
I am very new to this scene and have started to learn XNALara. I have little to no experience with 3d modeling. I have downloaded, posed some models and made some scenes. When I am importing a new model through noesis, I do not see textures, I see a blank model, its very large, and there are no bones. What thread should I be reading or posting to learn or get this information?

thank-you, again, I am not attempting to spam and I hope this question is in the right place. If not, I am sorry

[gladios6]

Can u reupload this model , her autor is inactif please ?

[perryloo]

Originally Posted by dougdude10

I have downloaded, posed some models and made some scenes. When I am importing a new model through noesis, I do not see textures, I see a blank model, its very large, and there are no bones.

With XNAlara you do have to import XNAlara models, to get it to work properly. I do not think noesis would be compatible with XNAlara.

There are many websites with XNAlara models available, characters, backgrounds, etc. You can ask on here, for a specific model you are looking for, and someone may find it for you, or even make it for you.