- Welcome to KatsBits Community.
KatsBits Community
KatsBits Knowledgebase Community for Blender
Recent posts
#1
News / Legacy ASE Exporter + Batch (A...
Last post by kat - April 14, 2026, 02:21:06 PM
"Legacy ASE Exporter + Batch (Add-on)" https://www.katsbits.com/codex/legacy-ase-exporter/ updated the very old ASE export script(s) for legacy content creation (idtech et al). Now includes Collection batching (to individual *.ase files) and axis flipping... Compatible with Blender 4.x & 5.x
#2
News / Re: FBX Batch Exporter Add-on ...
Last post by kat - April 03, 2026, 10:23:12 AMMinor update to the FBX Batcher + Rotation add-on, script needed a few tweaks to the UI and rotation values. Should be fixed now.
Installation
A bit fiddly but this ensures Blender clears the *.py script and Add-on repository (cache), forcing it to use the latest install instead of pulling in the cached version.
Installation
- Remove previous install and shut down Blender.
- (Re)open Blender and install the FBX Export Add-on
- Restart Blender
A bit fiddly but this ensures Blender clears the *.py script and Add-on repository (cache), forcing it to use the latest install instead of pulling in the cached version.
#3
News / Unity FBX Model Import Rotatio...
Last post by kat - March 31, 2026, 02:12:53 PM
"Unity FBX Model Import Rotation Fix" https://www.katsbits.com/codex/unity-rotation-fix/ taking a quick look at fixing Unity auto-rotating FBX models on import despite correct axes being set... grrrr
#4
Blog / Process vs. Problem Solving Mi...
Last post by kat - March 31, 2026, 01:58:52 PMHaving just posted a tutorial (Unity FBX Model Import Rotation Fix) on a particular way to work with, or around, the problem of Unity constantly auto-rotating models despite being exported with the correct orientation axes (Y/up, Z/Forward), a couple of comments suggested the solution to this was simply a matter of "changing the export settings", the implication being the tutorial is wrong because its not explaining the "right" way to do something, rather than it outlining what to do when the "right" thing doesn't work.
This is the "process mindset" in action; it sees a problem and presumes it can be fixed by simply making sure the correct settings are used. For Unity model import, that's just making sure to set the axes correctly, because of course that's the problem.
Except, Unity uses a heuristic algorithm that analyses meshes during import beyond the XYZ axes values that, if it thinks a mesh is wrong, it will apply the coordinate fix to compensate, rotating the model on one or more axes, regardless (for Blender that's typically -90° around the X axis).
When this happens, the "process mindset" hits a wall because it can't comfortably step outside the problem. Instead, the it looks at the rotation settings and can't figure out what the problem is, largely because it doesn't understand the entirety of the process its locked in to, that the issue may be being caused by something outside their segmented understanding of the process itself - "it worked before, why isn't it working now?".
The "problem-solving mindset" sees the same problem - correct axes, failed import - and asks whether something else is going on, and whether there's another way to get to the same end result. Often this might not be the procedurally "correct" way to do something, getting models to behave correctly in Unity, but it'll work.
To the "process mindset" folks, this is a bad thing, because its not the correct thing, even though it works fine and produces the desired end result. And they will let everyone know.
For the "problem-solving mindset" they'll make a note of the problem and how it was solved so it can be used the next time the issue occurs. And they too, might let everyone know.
Both attitudes, or approaches, have their place; the "process mindset" tends to keep standards high or locked-in, whereas the "problem-solving" mindset remains flexible and keeps things moving when set processes don't work or match reality.
Learning to recognise the difference is a part of the craft no one really says anything about.
P.S. there's obviously a difference between "problem solving" and just throwing stuff at a wall to see what sticks.
This is the "process mindset" in action; it sees a problem and presumes it can be fixed by simply making sure the correct settings are used. For Unity model import, that's just making sure to set the axes correctly, because of course that's the problem.
Except, Unity uses a heuristic algorithm that analyses meshes during import beyond the XYZ axes values that, if it thinks a mesh is wrong, it will apply the coordinate fix to compensate, rotating the model on one or more axes, regardless (for Blender that's typically -90° around the X axis).
When this happens, the "process mindset" hits a wall because it can't comfortably step outside the problem. Instead, the it looks at the rotation settings and can't figure out what the problem is, largely because it doesn't understand the entirety of the process its locked in to, that the issue may be being caused by something outside their segmented understanding of the process itself - "it worked before, why isn't it working now?".
The "problem-solving mindset" sees the same problem - correct axes, failed import - and asks whether something else is going on, and whether there's another way to get to the same end result. Often this might not be the procedurally "correct" way to do something, getting models to behave correctly in Unity, but it'll work.
To the "process mindset" folks, this is a bad thing, because its not the correct thing, even though it works fine and produces the desired end result. And they will let everyone know.
For the "problem-solving mindset" they'll make a note of the problem and how it was solved so it can be used the next time the issue occurs. And they too, might let everyone know.
Both attitudes, or approaches, have their place; the "process mindset" tends to keep standards high or locked-in, whereas the "problem-solving" mindset remains flexible and keeps things moving when set processes don't work or match reality.
Learning to recognise the difference is a part of the craft no one really says anything about.
P.S. there's obviously a difference between "problem solving" and just throwing stuff at a wall to see what sticks.
#5
Blog / Even AI is Confused by Blender...
Last post by kat - March 30, 2026, 04:49:48 PMWhile writing up the "Unity FBX Model Import Rotation Fix" tutorial, (Opera) AI was consulted to double-check axes and coordinate differences to make sure Up is up and Forward is forward depending on the editing environment. It turns out even AI is confused by Blender!
Maybe it's the way the questions were phrased, but this raises an interesting point about the reliability of AI, even for relatively well known and established 'facts'; if the questioner doesn't know the 'correct' answer, meaning they're able to double-check the information being double-checked, they won't know if the answer provided by AI is correct.
Q: Clear something up; in Blender 3D the -Y axis represents Forward, and +Z represent Up, is that right?
A: In Blender 3D, the axis orientation is indeed as follows:
• The -Y axis represents Forward (the direction you move forward in the default view).
• The +Z axis represents Up (the vertical direction).
So yes, your understanding is correct. Blender uses a right-handed coordinate system where:
• X axis points to the right,
• Y axis points backward (so -Y is forward),
• Z axis points upward.
This is a standard convention in Blender for navigation and object orientation.
Q: So, when the viewport is in "Front" orthogonal view, the users point-of-view is looking *backwards* along the +Y axis?
A: Yes, when the viewport is set to the "Front" orthogonal view in Blender, the user's point of view is looking backward along the +Y axis.
To clarify:
• The "Front" view in Blender looks toward the scene from the front, meaning you are positioned on the +Y axis looking toward the origin.
• Since the forward direction in Blender is along the -Y axis, looking from the front means you are looking backward along the +Y axis.
So effectively, in the Front orthographic view, you are looking from positive Y toward negative Y, which is backward relative to the forward direction (-Y).
Q: Shouldn't that be the other way around? You're looking at the +Y (backwards) *from* the -Y (forwards) point of view?
A: I understand the confusion—3D coordinate systems can be tricky! Let's clarify carefully:
In Blender:
• The Forward direction is along the -Y axis.
• The Back direction is along the +Y axis.
• The Up direction is along the +Z axis.
When you switch to the Front orthographic view, Blender places the camera (the viewpoint) on the +Y axis, looking toward the origin (which is toward the -Y direction). So:
• You are looking from +Y toward -Y.
• Since -Y is Forward, you are looking forward into the scene.
• The scene in front of you extends along the -Y axis.
So, the user's viewpoint in Front view is at positive Y, looking toward negative Y (forward).
In other words:
• You are at +Y, looking toward -Y (Forward).
• The "Front" view shows you the scene as if you are facing forward.
This means you are looking at the -Y axis (Forward) from the +Y axis (Back).
So your intuition is right: the viewpoint is located on the +Y side, looking toward -Y (forward), not the other way around.
Q: Right but in Front View, you should be actually looking *backwards* into the scene (relative to grid centre), along the +Y? What you seem to be describing is the view being set to *Backwards*, which *would* mean you looking *forward* into the scene?
A: Let's clarify the Blender viewport views and directions precisely, as this is a common point of confusion.
Blender Coordinate System Recap:
• Forward direction: -Y axis
• Backward direction: +Y axis
• Up direction: +Z axis
• Right direction: +X axis
Viewport Views and Camera Directions:
• Front View:
o The camera is positioned on the -Y axis (negative Y side).
o The camera looks toward +Y (positive Y direction).
o So, in Front View, you are looking along +Y into the scene.
o This means you are looking backwards relative to the forward direction (-Y).
• Back View:
o The camera is positioned on the +Y axis (positive Y side).
o The camera looks toward -Y (negative Y direction).
o So, in Back View, you are looking along -Y into the scene.
o This means you are looking forward relative to the forward direction (-Y).
What this means:
• In Front View, you look backwards into the scene along the +Y axis.
• In Back View, you look forward into the scene along the -Y axis.
Why this is confusing:
• The Forward direction in Blender is -Y.
• The Front View camera is placed on the -Y side, looking toward +Y.
• So the Front View shows you the scene from the front, but you are actually looking backwards relative to the forward direction
Conclusion:
You are correct in your understanding:
In Front View, you look backwards along +Y into the scene.
What I described earlier was inverted.
Thank you for pointing that out! This is a subtle but important distinction in Blender's coordinate and viewport system.
Maybe it's the way the questions were phrased, but this raises an interesting point about the reliability of AI, even for relatively well known and established 'facts'; if the questioner doesn't know the 'correct' answer, meaning they're able to double-check the information being double-checked, they won't know if the answer provided by AI is correct.
# # #
Q: Clear something up; in Blender 3D the -Y axis represents Forward, and +Z represent Up, is that right?
A: In Blender 3D, the axis orientation is indeed as follows:
• The -Y axis represents Forward (the direction you move forward in the default view).
• The +Z axis represents Up (the vertical direction).
So yes, your understanding is correct. Blender uses a right-handed coordinate system where:
• X axis points to the right,
• Y axis points backward (so -Y is forward),
• Z axis points upward.
This is a standard convention in Blender for navigation and object orientation.
Q: So, when the viewport is in "Front" orthogonal view, the users point-of-view is looking *backwards* along the +Y axis?
A: Yes, when the viewport is set to the "Front" orthogonal view in Blender, the user's point of view is looking backward along the +Y axis.
To clarify:
• The "Front" view in Blender looks toward the scene from the front, meaning you are positioned on the +Y axis looking toward the origin.
• Since the forward direction in Blender is along the -Y axis, looking from the front means you are looking backward along the +Y axis.
So effectively, in the Front orthographic view, you are looking from positive Y toward negative Y, which is backward relative to the forward direction (-Y).
Q: Shouldn't that be the other way around? You're looking at the +Y (backwards) *from* the -Y (forwards) point of view?
A: I understand the confusion—3D coordinate systems can be tricky! Let's clarify carefully:
In Blender:
• The Forward direction is along the -Y axis.
• The Back direction is along the +Y axis.
• The Up direction is along the +Z axis.
When you switch to the Front orthographic view, Blender places the camera (the viewpoint) on the +Y axis, looking toward the origin (which is toward the -Y direction). So:
• You are looking from +Y toward -Y.
• Since -Y is Forward, you are looking forward into the scene.
• The scene in front of you extends along the -Y axis.
So, the user's viewpoint in Front view is at positive Y, looking toward negative Y (forward).
In other words:
• You are at +Y, looking toward -Y (Forward).
• The "Front" view shows you the scene as if you are facing forward.
This means you are looking at the -Y axis (Forward) from the +Y axis (Back).
So your intuition is right: the viewpoint is located on the +Y side, looking toward -Y (forward), not the other way around.
Q: Right but in Front View, you should be actually looking *backwards* into the scene (relative to grid centre), along the +Y? What you seem to be describing is the view being set to *Backwards*, which *would* mean you looking *forward* into the scene?
A: Let's clarify the Blender viewport views and directions precisely, as this is a common point of confusion.
Blender Coordinate System Recap:
• Forward direction: -Y axis
• Backward direction: +Y axis
• Up direction: +Z axis
• Right direction: +X axis
Viewport Views and Camera Directions:
• Front View:
o The camera is positioned on the -Y axis (negative Y side).
o The camera looks toward +Y (positive Y direction).
o So, in Front View, you are looking along +Y into the scene.
o This means you are looking backwards relative to the forward direction (-Y).
• Back View:
o The camera is positioned on the +Y axis (positive Y side).
o The camera looks toward -Y (negative Y direction).
o So, in Back View, you are looking along -Y into the scene.
o This means you are looking forward relative to the forward direction (-Y).
What this means:
• In Front View, you look backwards into the scene along the +Y axis.
• In Back View, you look forward into the scene along the -Y axis.
Why this is confusing:
• The Forward direction in Blender is -Y.
• The Front View camera is placed on the -Y side, looking toward +Y.
• So the Front View shows you the scene from the front, but you are actually looking backwards relative to the forward direction
Conclusion:
You are correct in your understanding:
In Front View, you look backwards along +Y into the scene.
What I described earlier was inverted.
Thank you for pointing that out! This is a subtle but important distinction in Blender's coordinate and viewport system.
#6
News / FBX Batch Exporter Add-on with...
Last post by kat - March 26, 2026, 03:03:41 PM
"FBX Batch Export Add-on with Rotation" https://www.katsbits.com/codex/fbx-batch-export-rotation/ an Add-on for batch exporting (static/non-animated) mesh objects in a Collection to FBX with axes of orientation data (including a fix for Unity's aggressive rotation filter for Blender exported files).
#7
Blog / Re: SCAM WARNING - eBusiness N...
Last post by kat - February 12, 2026, 06:32:22 PMEU Business Register
register@pzmedia.net
register@pzmedia.net
#8
Account Registration / Apply for a Forum Account
Last post by kat - February 12, 2026, 06:27:45 PMTo protect the forum from automated abuse, new accounts are issued by application.
The forum is publicly readable, but posting privileges require approval. Applications are reviewed manually. Most are processed within 24–48 hours. Incomplete or generic submissions will not be approved.
If you are a genuine Blender user and would like to participate in discussions please message KatsBits at community@katsbits.com with answers to the following questions (copy/paste into an email);
Q1: What version of Blender are you currently using?
Q2: What are you currently working on or trying to learn in Blender?
Q3: Have you read any tutorials or articles on KatsBits? If so, which one(s)?
Q4: What would you like to use the forum for?
Q5: What is the name of Blender's default cube object shown in a new file?
The forum is publicly readable, but posting privileges require approval. Applications are reviewed manually. Most are processed within 24–48 hours. Incomplete or generic submissions will not be approved.
If you are a genuine Blender user and would like to participate in discussions please message KatsBits at community@katsbits.com with answers to the following questions (copy/paste into an email);
Q1: What version of Blender are you currently using?
Q2: What are you currently working on or trying to learn in Blender?
Q3: Have you read any tutorials or articles on KatsBits? If so, which one(s)?
Q4: What would you like to use the forum for?
Q5: What is the name of Blender's default cube object shown in a new file?
QuotePlease note: Applications that appear automated, promotional, or unrelated to Blender will not be approved. This process exists solely to protect the forum from large-scale automated abuse.
#9
News / FREE Fantasy Asset Pack for Un...
Last post by kat - February 11, 2026, 03:51:01 PM
The Fantasy Asset Pack for Unity 3D is now available from Unity Store FREE (no $$$) under Unity's standard EULA.
First published in 2018 the asset pack consists a set of models that snap together on Unity's standard grid, to create a 'York Stone' (Olde Worlde) style environment. The set includes some 120+ mesh objects and 300+ prefabs, in a number of different textures.
• Fantasy Asset Pack for Unity 3D »
QuoteImportant: an issue may encountered opening or loading the Fantasy Asset pack into Unity Editor v6.x series, where mesh objects only appear when Shaded Wireframe Draw Mode is set, and then displaying only as a wireframe. In other modes, Unlit Draw Mode, Shaded Draw Mode or Wireframe Draw Mode, nothing is shown - objects can be selected in the Hierarchy, which outline highlights where the mesh is in the Scene, despite it not being visible. See "Unity Editor & Broken or Corrupt Mesh/Object Display" for fix to this problem. Asset pack opens/loads correctly in version v 5.x (all) of Unity Editor
Images
Examples shown below in their original state for clarity.
#10
FAQ on games, gaming & IT / Problem With Unity 3D Publishe...
Last post by kat - February 10, 2026, 11:25:40 AMUnity ID Tax Number
To withdraw payments from Unity Store as a publisher, account holders need to be properly registered as being a 'business' entity or and individual. Aside from the usual identity information Unity ID requires a Tax Number be as part of that process. However, for non-United States of America residents (or registered businesses) the 'tax number' provided by local tax authorities may not work - the number can be input but Unity ID will report it as invalid.
The source of the issue seems to caused by a conflict in the way Unity describes what it wants, versus what it actually wants.
In other words Unity ID/Store is asking for a Tax Identification Number, or Unique Tax Reference as they're called in the United Kingdom, that identifies a business (Limited Company, Sole Trader etc.), but is actually expecting a VAT number (Value Added Tax or Sale Tax identifier), a property usually associated with registered business entities. The mismatch causes Unity to throw the 'invalid' error.
Unity Store Business ID
The fix, at least for publishers outside the United States, is to click the link under the Tax Number input field and switch to Business Number. Entering a valid Tax ID, for example a UTR if based in the UK, should then been seen as valid, granting access to fund withdrawals - a Tax ID should be issued by the relevant tax authorities wherever publishers are registered as business/self/employment concern.
To withdraw payments from Unity Store as a publisher, account holders need to be properly registered as being a 'business' entity or and individual. Aside from the usual identity information Unity ID requires a Tax Number be as part of that process. However, for non-United States of America residents (or registered businesses) the 'tax number' provided by local tax authorities may not work - the number can be input but Unity ID will report it as invalid.
The source of the issue seems to caused by a conflict in the way Unity describes what it wants, versus what it actually wants.
In other words Unity ID/Store is asking for a Tax Identification Number, or Unique Tax Reference as they're called in the United Kingdom, that identifies a business (Limited Company, Sole Trader etc.), but is actually expecting a VAT number (Value Added Tax or Sale Tax identifier), a property usually associated with registered business entities. The mismatch causes Unity to throw the 'invalid' error.
Unity Store Business ID
The fix, at least for publishers outside the United States, is to click the link under the Tax Number input field and switch to Business Number. Entering a valid Tax ID, for example a UTR if based in the UK, should then been seen as valid, granting access to fund withdrawals - a Tax ID should be issued by the relevant tax authorities wherever publishers are registered as business/self/employment concern.