Jump to content

Blender import export script outdated


Recommended Posts

Hello everyone!

 

I have noticed that there are not many new mods dragon age origins that include new models, animations, textures for new models...

I believe reason for this is that we have tools that are outdated, and don't really allow us to do mods like what people are doing in Skyrim (lots of animations, body and armor models, hairstyles...)

 

So what this topic is about?

There is this great tool Dragon Blender that has been left unfinished and became outdated

http://dragonage.nexusmods.com/mods/268/

 

My questions are:

 

Is there anyone who can make use of it and create new import export script and create fully functional tool?

 

Is there anyone who can make changes to existing tool and make it compatible with new versions of Blender and Python?

 

If both answers are NO then my question is why not? What is exactly the problem? What is it that changed so much in new version of Blender that makes it no longer possible to create fully functional import-export script for DAO?

 

I have also noticed that there are similar issues with modding Skyrim with Blender.

So why are this scripts not getting updates to work with new versions?

Link to comment
Share on other sites

My questions are:

 

Is there anyone who can make use of it and create new import export script and create fully functional tool?

 

Is there anyone who can make changes to existing tool and make it compatible with new versions of Blender and Python?

 

If both answers are NO then my question is why not? What is exactly the problem? What is it that changed so much in new version of Blender that makes it no longer possible to create fully functional import-export script for DAO?

 

I have also noticed that there are similar issues with modding Skyrim with Blender.

So why are this scripts not getting updates to work with new versions?

Question 1: Yes, even I could do it if you give me enough time.

 

Question 2: Likely, no. You see, newer versions of Blender (2.5x, 2.6x) use Python 3.x which brought some big changes, Py2 scripts are incompatible with it and need a lot of editing (or scrapping them completely and starting from scratch) to make them work. Not to mention that Blender 2.5x/2.6x also brought some big changes, which only makes things harder.

 

Question 3: Why are they not updated? Because those who need to edit them, first need to learn how to use Python 3.x, then need to learn about how the new Blender works, and only then can they start writing new scripts (likely from scratch) which takes a long time. It's more likely that Blender 2.49 will be used for a while longer since it works on old Python 2 and most know how it works.

Link to comment
Share on other sites

Thank you for quick answer. Now few more questions:

1. Would you do it?

2. How can someone do a script that would not be messed up each time blender or python changes?

- is it possible to make this tool in some other language and make it work in blender?

3. Where can we learn how to create import export script for blender (its good to know this for some future games)?

Link to comment
Share on other sites

1. Would you do it?

2. How can someone do a script that would not be messed up each time blender or python changes?

- is it possible to make this tool in some other language and make it work in blender?

3. Where can we learn how to create import export script for blender (its good to know this for some future games)?

1. No. Not that I don't want to you see, it's that I don't have DA:O and I use Linux (I don't have Windows) which means some Python functions are incompatible with Windows' (Python location pops into mind first, /bin/python2.5 as opposed to C:\Python2.5, which I have to include due to the fact that Linux uses Python 3.3.2 as main).

 

2. Simple, you can't. Python changed a lot, the simple print went from a statement to function, from

print "Hello world!"
to

print ("Hello world!")
which means every print command inside a script with a few thousand lines of code needs to be changed to reflect the changes. And that would be easy, but it's not just print that was affected and Python changes regularly, so there is no way you can "make it so it works for all". Constant updates are required.

 

Also, and this is a big maybe, it may be possible to make the tool in another programming language, but you would still need a python script that imports it for use in Blender (which is bound to Python). I'm not sure about that though, I know I can execute a Python script in Linux and import a Shell script for use (and vice versa) but an import/export plugin for Blender, I'm just not sure.

 

3. Import/export scripts specifically - nowhere. The only way to learn something like that is by learning Python programming language, this is a "good" beginners tutorial (written for total beginners, but aimed at Python 2.x) and for anything more, you'll have to look at the Python documentation. Then you need to reverse-engineer the models to learn how they are made, examine Blender to figure out how to take advantage of it's existing functions, and then you can begin creating an import/export script.

 

Note that it's no easy task though, once the script reaches over 1000 lines you'll have a nightmare maintaining it, I currently have a 1500+ lines program which makes my head hurt each time I see it, for comparison, nif scripts for Blender have cca 4000+ lines.

Link to comment
Share on other sites

Just some advice from experience aka failures, head-bashing and hair pulling. Porting the scripts between 2.49 & 2.6 is a pretty big undertaking.

 

Assuming you want to build for recent versions of Blender(2.6+) at least. The first thing to note is that you will be using the in-built version of python 3.2/3.3 so that is what you will be coding for. This is a full embedded version of Python. The issue about file pathing between different OS's is a bit of a null. Blender and pythons is able to handle alot of that for you if do it right.

 

Generally you will want to code towards the Blender Add-on scheme. This will allow you to structure the install the addon as a zip file which can be loaded directly into Blender via its add-on system. This also has the added advantage that if you do have any additional dependancies which are not available in the default install they can be included that way. Having users install things manually leads to no end of issues. We have a separate module that reads/writes files.

 

Having looked at the scripts although my 2.49b is rusty they don't seem too bad condition. You will need to decompile some files as there doesn't seem to be a corresponding .py file. Not being on my dev machine I am glossing over things. Structuring your code is what will really save you alot of effort in the long run.

 

You brought up about have things change between different versions of Blender. Between 2.49 & 2.5 Blender underwent a huge rewrite internally and the way that you talk to Blender via python is just not the same. In-fact some of the modules that you used to talk to either work differently now or no longer exist.

 

This is the nature of the pace that Blender development cycle. They add new functionality with each cycle and to support that the Blender python API gets updated frequently. Accounting for this is something that you need to work into your dev cycle. We developed automated test suite that we run to see if new version breaks things, then we go and fix it. Even with this, we are at an early stage and are only targeting once version until we have enough features working well enough that breaking them and fixing them is not as bad :P

 

Just some fun, the current codebase has over 10K+ lines of production code, which does not include pyffi used to read/write the actual files, thats probably another 20-30k. The test suite is currently only 5k as it covers a fraction of the code and has a long ways to go before its can be considered production ready.

 

If you need any advice give us a shout.

Link to comment
Share on other sites

Thank you that was helpfull. Ill be honest Im just a beginner in all this (I would rather that someone else more experienced tries to revive whole DAO modding with up to date tools) but i intend to focus on Blender so knowing things like this will be great in some future projects. Idk how far ill get with this import export script for DAO coz there is not much info on writing any import export script for blender online... but at least ill learn python for something else (Currently at 51% on that link that Werne posted. Maybe im going to fast, maybe its not as difficult as C++ or VBA. Anyway nice tutorials).

I think bigger problem will be to learn how Blender works... and yeah script should be in python 3.x and for blender 2.6 or newer. I was reading an article about the future of blender and seems even if i make something it will soon lose compatibility with newer versions... http://code.blender.org/index.php/2013/06/blender-roadmap-2-7-2-8-and-beyond/

Link to comment
Share on other sites

Porting the scripts between 2.49 & 2.6 is a pretty big undertaking.

You don't say. :P

 

I ported one script (not a Blender script, a small utility I wrote) over from Py2 to Py3, about 300 lines of code, and I wanted to throw my PC out the window and run it over with a lawnmower more than a few times. Now I just mix it up with Bash when I work with Python, easier for me that way.

 

The issue about file pathing between different OS's is a bit of a null. Blender and pythons is able to handle a lot of that for you if do it right.

I know that but there are some other things that differ between Linux's and Windows' Python aside from paths.

 

For example, in Linux I use "clear" for clearing the terminal output while on Windows I had to use "cls", mixing them up results in an error message and the script terminates immediately afterwards on Windows (keeps working on Linux though), both commands do the same thing. Also, Windows file path is not case sensitive while in Linux it is, which results in my brain exploding when I forget that.

 

Even so, things can be done so it works on both operating systems, it's just that I find it a giant pain in the arse sometimes.

 

If you need any advice give us a shout.

I'm good, but I could use some info. Seeing as how you have a lot of NifTools stuff in your signature, and you seem to be quite knowledgeable about it, do you by any chance know at which Blender/Python version will the next nif scripts be aimed and will the new scripts be backported to 2.49b or will nif support be dropped for 2.4x Blender and Py2? Linux support will likely come later on and that's ok, I might even pitch in when it comes to that, if I have time that is.

 

I'm asking cause I'm running Arch which is a bleeding-edge distribution, meaning that Python/Blender are the latest version at all times. In case a newer 2.6x Blender is to be supported, I'd like to block pacman from updating those packages or downgrade them before it can cause the system to crash and burn. If I downgrade/block before new updates arrive, I can make the necessary changes to keep my system stable later on.

 

Other options are to change the scripts myself for newer Blender/Python Arch has in the repositories, or use Ubuntu (yuck :yucky:) for 3D modeling. While I'm ok with the first option (at least I get to practice my Python), the second is out of the question.

 

Currently at 51% on that link that Werne posted. Maybe im going to fast, maybe its not as difficult as C++ or VBA.

While it is simpler than C++ and VBA, mostly it's the fact that the tutorial is written for dummies. I passed it 100% in two days and then I got stuck on a simple script cause it didn't cover the part I needed, that tutorial is just an introduction to Python.

 

To simplify - You still have much to learn, young Padawan. :P

 

By the way, if you need a tool for making/editing scripts (syntax highlighting is handy), my advice would be either Notepad++ or gedit (GUI editors, gedit is cross-platform). I personally prefer gedit from the two even though I use nano and vim which are CLI editors, I like the 80s feeling, it goes well with the sound of a 30 years old IBM mechanical keyboard. :cool:

 

at least ill learn python for something else

And that is the biggest advantage of knowing at least one programming language - if you need/want something that doesn't exist, you can make it yourself. :thumbsup:

 

And if you really want to learn the language well, get Arch testing or Debian Experimental, you'll be writing half the programs yourself since most are either non-existent or they blow up half of your OS when they don't work with new updates. After a few months of that you'll be able to recite Python functions by their order in the alphabet. ;D

Link to comment
Share on other sites

Thank you that was helpfull. Ill be honest Im just a beginner in all this (I would rather that someone else more experienced tries to revive whole DAO modding with up to date tools) but i intend to focus on Blender so knowing things like this will be great in some future projects. Idk how far ill get with this import export script for DAO coz there is not much info on writing any import export script for blender online... but at least ill learn python for something else (Currently at 51% on that link that Werne posted. Maybe im going to fast, maybe its not as difficult as C++ or VBA. Anyway nice tutorials).

 

 

Unfortunately for alot of "these" projects, waiting for that someone else to turn up rarely happens. If you want something often you have to do it yourself.

 

 

I think bigger problem will be to learn how Blender works... and yeah script should be in python 3.x and for blender 2.6 or newer. I was reading an article about the future of blender and seems even if i make something it will soon lose compatibility with newer versions... http://code.blender.org/index.php/2013/06/blender-roadmap-2-7-2-8-and-beyond/

 

Ah the roadmap, was wondering when/if that would appear.... I have been talking to the Blender dev's about this and parallel development tracks merging backward or forwards is going to be all sorts of fun for the developers. It is however the logical choice to ensure Blender maintains its momentum while allowing areas to be ripped apart.

 

Either way, see previous point about the nature of the Blender beast, it will keep on rolling on, you have to learn to go along for the ride or get left behind. If you are ok with that then target a specific version and hope compatibility remains for long enough to get things done. At the same time worrying about what could happen you would never get anything done. Accepting change will happen and checking to see what gets broken is the better approach.

 

 

You don't say. :P

 

I ported one script (not a Blender script, a small utility I wrote) over from Py2 to Py3, about 300 lines of code, and I wanted to throw my PC out the window and run it over with a lawnmower more than a few times. Now I just mix it up with Bash when I work with Python, easier for me that way.

 

Porting between py2.x & py3k is pretty easy, there are plenty of automation scripts. I think one of our libraries is built using 2.6 and it runs the py2to3 script which comes with the python install to build for 3k. Still it really depends on what the code is.

 

 

I know that but there are some other things that differ between Linux's and Windows' Python aside from paths.

 

For example, in Linux I use "clear" for clearing the terminal output while on Windows I had to use "cls", mixing them up results in an error message and the script terminates immediately afterwards on Windows (keeps working on Linux though), both commands do the same thing. Also, Windows file path is not case sensitive while in Linux it is, which results in my brain exploding when I forget that.

 

Even so, things can be done so it works on both operating systems, it's just that I find it a giant pain in the arse sometimes.

 

In those cases I would write individual scripts, square pegs and round holes. Using python to check which environment you are on, you can call a specific script the best tools for the job. Though I did always manage to get the triangle one to fit into that square hole. Take that early childhood.

 

 

I'm good, but I could use some info. Seeing as how you have a lot of NifTools stuff in your signature, and you seem to be quite knowledgeable about it, do you by any chance know at which Blender/Python version will the next nif scripts be aimed and will the new scripts be backported to 2.49b or will nif support be dropped for 2.4x Blender and Py2? Linux support will likely come later on and that's ok, I might even pitch in when it comes to that, if I have time that is.

 

I'm asking cause I'm running Arch which is a bleeding-edge distribution, meaning that Python/Blender are the latest version at all times. In case a newer 2.6x Blender is to be supported, I'd like to block pacman from updating those packages or downgrade them before it can cause the system to crash and burn. If I downgrade/block before new updates arrive, I can make the necessary changes to keep my system stable later on.

 

Other options are to change the scripts myself for newer Blender/Python Arch has in the repositories, or use Ubuntu (yuck :yucky:) for 3D modeling. While I'm ok with the first option (at least I get to practice my Python), the second is out of the question.

 

No there won't be any back-porting; we are not really porting, more code re-use where possible, which is usually a lot less than hoped.

 

Cross-platform support is out of the box, always has been, we code platform independently and platform specific tools do the rest for us. Installation is via the add-on installer so is platform independent. We do however have a self imposed target 2.62 as getting the current milestone feature-set sufficiently supported before breaking it again. For more in-depth reasons, that is why those links are provided.

 

As an Arch user I would have thought that you would be more of the view of what something can do or be useful to the user rather than the not? But I suppose the rabbit hole runs quite deep :D

Link to comment
Share on other sites

As an Arch user I would have thought that you would be more of the view of what something can do or be useful to the user rather than the not? But I suppose the rabbit hole runs quite deep :biggrin:

I have a feeling you're poking me with a stick and expecting a reaction. Well, it won't work. :armscrossed:

 

 

 

Told you it won't w... damn it, gimme that stick! Damn these modding tools, they drive me to make them.

 

I don't suppose you have an idea where I can take a peek at the code for new nif scripts? Python is not exactly my native language but then again, neither is UNIX shell and I nailed it within a month, I'm pretty sure I can help in some way. :smile:

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...