3DVIA.com Forums » 3DVIA Virtools » Wish List

XML import / export of projects

(6 posts) (6 voices)
  • Started 8 years ago by #greggman
  • Latest reply from #bikhyal

  1. #greggman

    enthusiast
    Joined: Feb '04
    Posts: 73

    Virtools is extremely buggy. Maybe it's only one or two real bugs but as they effect lots of stuff feels really buggy.

    For example I have a bug where every time I save my CMO I get an error about saving 2 of the joints in a particular character. Realoding the CMO I never noticed a real problem but recently it morphed into an error about saving the textures. Now when I reload my CMO those textures are missing.

    There are other issues too. For example make a script, in that script make a local parameter. make another script. Copy the local paramater and paste as shortcut into the new script.

    Save the new script only. Start a new project and load the script you just saved. Notice the there are red dataflow lines going off into nowhere and that if you continue to use Dev it will eventually crash.

    Exit/Restart Dev. Make a level script. From the Level Manager select the script, right click and save it. Start a new project, load the script, notice it's not connected to anything.

    I also have problem with characters and textures not appearing in the Level Manager but they appear in the lists where you can select a character or texture.

    Anyway, of course the #1 wish is that these bugs be fixed but on top of that if there was an XML exporter and XML importer option then just maybe when these kinds of things happen we could export the entire CMO to XML and then walk through it by hand to find what is wrong with it. As it is, once the CMO is trashed we have to start our entire project from scratch. Sometimes we can go back a few versions but often whatever the error was seems to be burried inside the CMO such that after a few more iterations the error comes back.

    That makes it impossible to salvage anything out of a bad CMO since you never know which part is bad. Maybe I'm dreaming but if I could export to some human readable format then I could hopefully see which piece is bad and I could certainly cut and paste parts that are good into some other XML file and reimport.

    XML import and export would also make it easier to write other kinds of tools that could get data inside virtools. Not just any data but various code generators for example.

    Posted 8 years ago #

  2. Hightree

    power user
    Joined: Feb '01
    Posts: 3,106

    If you can reproduce those errors, please send a bugreport with the concerned files and a reproduction instruction to virtools.

    No software is 100% and as a developer, these hard to explain, real-life bugs are hard to get.

    About an xml exporter, I don't know how helpful it would be. I can imagine that if you've got an idea where to look, then yes.

    But I also think one could get lost pretty easy...

    In the meantime, maybe its an idea to try and get to the info you're looking for by running a debug session from msdev and inspecting virtools' data structures at runtime.

    Posted 8 years ago #

  3. #greggman

    enthusiast
    Joined: Feb '04
    Posts: 73

    >No software is 100% and as a developer, these hard to explain,

    >real-life bugs are hard to get

    True. The difference is with virtools, 100% of my project is inside Virtools and it only takes one bug to kill the entire project. In the course of developing a commerical game with normal tools we often run into bugs, especially in complicated programs like Maya or Max. But when we run into those bugs it's generally 1 file out of thousands that make up the entire project.

    In Virtools, since the entire project is in one .CMO file then any bug which corrupts that file destroys the entire project. Because of that, Virtools needs to be held to a higher standard for bugs. Even knowning that because it's a complicated program it will have bugs there are quite a few things Virtools could do to prevent them.

    For example, currently Virtools doesn't check if an .NMO is using too many vertices. It just happily loads the file and then crashes. If it doesn't crash then memory is corrupted. Saving at that point gives you a bad .CMO. Virtools should check both on exporting and importing if the files are valid.

    Virtools will also sometimes corrupt itself if you paste schematic from one script to another and those scripts are not of the same time of object. If you are lucky it crashes immediately. If you are unlikely it just silently corrupts itself and when you save your project the .CMO will be corrpt.

    Virtools will often corrupt itself if you duplicate characters or copy, load or paste animations.

    It's not just a bad/corrupt .CMO that's the problem, if you are picking "Save Version" often as you would expect someone to that is using complicated software you have no idea in which version the corruption started so you don't know how far back you need to go.

    Knowing that you won't find every single bug the next best thing is to program defensively and give us, the users, every chance to recover our work. A file format that we could easily look at might let us do that.

    There would be other benefits too. for example Renderware will export all of its current project's local parameters into a C file. You can hand edit that C file and then re-import it into Renderware. I'm not suggesting a C file for Virtools but the point is, sometimes it's eaiser to edit in text. I would much rather do a search and replace or use a text macro to change lots of stuff in an XML file then to have to manually enter 30-100 scripts and hand edit a local parameter somewhere. An XML file format would let me do this.

    Another issue that comes up, maybe I'm just not familiar enough with Virtools. Is merging local parameters. If I have one script that uses a local param called "speed" and another that uses one called "speed" and I actually want them both to be the same parameter how do I do it? Manaully deleting "speed" on one of them and hand pasting a short cut from the other? If I've got a lot of them that's a pain. An human readable file would let me go in and fix this kind of stuff until you guys have time to make fancier editors.

    Posted 8 years ago #

  4. #david callele

    veteran
    Joined: May '01
    Posts: 233

    Greggman, you make a lot of valid points. However, it also appears that you are a relatively new user of Dev (welcome!) so you may not be building your applications in the most "Dev-friendly" manner.

    At the simplest, you should be building independent objects that are saved in independent NMOs that are dynamically loaded at runtime. Make use of attributes and messages as much as possible. Make the encapsulation around each NMO as rigid as possible.

    And always save versions as often as you can :-)

    I once posted a mini-tutorial on the Swapmeet about the general architecture - if you search on my name you should be able to find it.

    Good luck!

    [This message has been edited by David Callele (edited 31 August 2004).]

    Posted 8 years ago #

  5. #andik

    enthusiast
    Joined: Jan '04
    Posts: 99

    Yes, luck is what you need when developing with Virtools. Sometimes it's like using a beta-version, where you constantly find out what's possible and where the limit of the program is.

    The XML im/export would be a handy feature, e.g. when copying parts of a script into another one (in a second dev window), which is not possible with copy/paste. But I am also not sure how helpful it would be, I think the developers have to focus on other major bugs (see troubleshooting section)

    Greggman, I've get used to it and I operate "Dev-friendly", looking at dev-crashes as part of the workflow... I have been working with it for 9 months now, developing a edu-game and now at a company (considering the amount they had to pay, all these bugs and the instability are actually barely acceptable...).

    But eventually I have to say that Virtools [b:1nx98vxi]is[/b:1nx98vxi] the best choice and I always recommend it to other people, because it is extremely powerful and fast, despite all the flaws.

    Posted 8 years ago #

  6. #bikhyal

    new member
    Joined: May '09
    Posts: 1

    i faced the same problem as well and apparently it is because of using same shaders or same materials or same textures on different meshes. In my project I kept using (drag and drop) the Normal Bump shader from Virtools resources and saving it by different names. But later after using it for about 20-30 objects it did not let me save anymore.

    anyhow I tried making the normal bump shader in this way: at the top of material setup there is slot beside edit shader which you can add normal bump. that's how I created it.

    hope this helped cause i spent hours to fix the problem right before my submission, and I understand that is super freaky not to be able to save your file.

    Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.