Small bugs

Report any Bugs you've found in JPatch here. IMPORTANT:Please post bugs found in a beta or development version into the Beta forum!

Small bugs

Postby dcuny » Sun Jul 10, 2005 10:43 pm

Now that I've got the CVS version, I can verify a couple bugs:
  • Properties set in Animator via mouse don't "stick". For example, if I scale an object using the buttons and mouse, then try to rotate it using the buttons and mouse, it'll pop back up to it's original size.
  • Inyo doesn't seem to be getting animation changes. This is different than the prior bug, in that even if the attributes stick (and the animation shows using the playback buttons), Inyo doesn't render the object with those settings. Oddly enough, I can move the lightsource and it'll reflect the position properly.
  • The animator doesn't seem to remember the last opened directory. For example, if I open a model from a directory, I'd expect that directory to be selected the next time I choose the "Open" dialog.
  • If a model from the scene file isn't found, the animator silently fails. (Well, it throws a java.io.FileNotFoundException, but no explanation is given. I'd like it to at least give a dialog explaining that the file wasn't found, and perhaps asking if the user needs to set the Model Directory.
The "model not found" bug sort of opens up a whole can of worms. It assumes that all your models can belong to the same directory. But what happens when you have multiple projects with the same object, but they need to be different?

Perhaps there should be a JPatch "root" directory. Under this directory, there can be multiple projects. Each object in the project should have an attribute: "shared" or "private". Things with a "shared" attribute (the default) get placed in the JPatch Root/Models directory. Things with the "private" directory get placed in the JPatch Root/[i]ProjectName directory.

There could be an option to "zip" a project (similar to a .jar file). You could then copy projects back and forth from different machines.

At the moment, you can only have a single "scene" in an animation project. I think it would be a good idea to allow multiple scenes in a project, instead of having to create a new project for each scene.

I suspect that it's a lot more complex than that, but it's a start... :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Mon Jul 11, 2005 6:35 am

I'll have a look at those issues. About locating resources from animation files: Once option would be a "search patch". But everyone using java knows the pain with its classpath, so I think this is not an option. Recursivly scanning directories from a given root would be better, but what if you have two files with the same name in different subdirectories?

I think the answer are project files. These would be zip files with a fixed directory structure. You could import and export models and other files into/from these zip files (using JPatch) - and all files required by a project must be in this zip file.

This could also solve the problem of rotoscope images in model files. I think embedding encoded binary files into xml is not a good idea.

And yes, a project files should support multiple scenes (or sequences, I'm not sure how they call it in CGI motion pictures).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Jul 11, 2005 8:27 am

As I was writing up the description, it occured to me that the the thing I wanted to do was be able to have a shared resource that could be used by a number of projects. This would typically be a model, but it could also include things like reusable motions, environment maps and materials. The idea was that if I updated some part of the model - the mesh, the morph, etc. - it would be "automatically" propogated to all the projects that used that model.

I'm not especially familiar with how this works in other applications. I know that A:M has a structure for objects, materials, and so on. On the other hand, AoI and Blender don't have this, and they've been criticized for that.

The idea of having projects as a collection of resources in a directory appeals to me in that it's got simplicity. It also makes it easy to grab things from one project and move them to another. Finally, there's always that worry that the project might get corrupted, and everything inside it would be lost.

On the other hand, keeping the project as a .zip is nice because you don't have an extra step of zipping or unzipping - it's all handled by JPatch. Plus, you're guaranteed that when you give someone a project, you won't be missing anything critical in it.

Because they're .xml files, JPatch models can be fairly large. I imagine you'd get a good compression via .zip.

The only real issue is one of being able to globally save changes to a model to all the other projects that use it. One option would be to have a timestamp on the model, and if it's a shared model, compare it to the one in the library. If the one in the library is more current, issue a warning that a more current version of the model was found in the library, with an option to replace the older model with the newer version. (Of course, you'd want an option to turn this check off).

The only downside is that it would only check for an updated version when you opened a project. So if you changed the model, and sent someone a different project, they wouldn't get the latest version of the model in the project... :?

Does this sound too complicated? Keep in mind I don't have any "real world" experience.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Mon Jul 11, 2005 9:20 am

I'm not sure if using a directory structure as a project is a good idea. I agree that it's easy to move files in/out, but you could also easily mess up the structure and JPatch wouldn't be able to open the project anymore. The save way to import/export things from/to the project would be doing it with JPatch, and in this case I think that an archive file is the better choice. But I'm open to discussion, if you think that a directory structure is better let's discuss the pros and cons.
I think there are a lot of tools out there that allow easy manipulation of zip-files, including drag and drop files between the zip and the file-system. But the "inhibition threshold" would be a little higher than with plain directories - i.e. you'd know that you are manipulating a project file and have to be careful.

I like the idea of shared resources. One way to implement it could be to have a pointer to another project:
Imagine the projects are zip files. You could have project A that includes some models, and project B that depends on project A, e.g. imports a model from project A. If you changed the model, it would print a warning and give you options to either create a "local" copy or to change the original in the project A file.
It would also be simple to add an option to create a "standalone" project (it would simply create a local copy of all shared resources, so if you move the file to another machine or share it with other users you can be sure that all required files are included.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Jul 11, 2005 10:22 am

In retrospect, I don't really have any issue with .zip files. I agree that they are "safer" to work with, as long as there are tools for doing import/export from within JPatch.

Given some more reflection, I think shared resources could potentially be a disaster for the average user. For example:
  • I create a model in Project A.
  • I make a "shared" copy in Project B.
All sorts of things could go wrong here:
  • I take Project B to another computer to do work, but forget to include Project A. I'm baffled to find my model is missing.
  • I delete Project A. Project B is now worthless.
I think the safest route to take would be to create a complete copy of all the resources, (so the project is stand-alone), but also maintain the sort of link you suggested.

Also, what happens when you copy the model from Project B to Project C? What project is listed as the parent? (I can see why Blender didn't take this route). :roll:
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am


Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest

cron