cochrane / gllara Goto Github PK

Examples: The lights in Russia/Kazakhstan. I'll have to take a close look at XNALara, how the problem is solved there. Right now, I have no idea.

All parts of the model are black. Adjusting the lighting has no visible effect. However, alpha-blended parts are shown correctly.

When a file is opened, both new or an existing one, it always shows up as "modified". This probably has something to do with the different sizes with and without the bottom bar, since the size of all render windows is stored in the model.

No real reason; I'm just curious and hope that this could help me identify images done with GLLara.

As described at http://xnalaraitalia.deviantart.com/journal/XPS-10-9-4-Wardrobe-Edition-349764705.

If a texture is missing, simply load its default texture. Inform a user about this! Since users can now add their own textures, they can easily fix such issues themselves.

Based on the XNALara source code, it seems the features that are most relevant include:

• Left mouse dragging while Q,W,E is pressed changes that particular axis. I'd like to use different keys here, since I used WASD to move around. Maybe XYZ to be really trivial? This is the key part here.
• Both mouse dragging changes where the camera is looking at, as does left mouse dragging with shift and left mouse dragging alone but in a different way. I already have that for left mouse dragging simply and want to keep that. Reversal with modifier key might work, though.
• Left mouse + ctrl dragging moves the object in the X/Z plane. That sounds like a very good idea, but the modifier should be a different one, so this can stay right-click.
• Right dragging changes camera distance. Uncertain about this one; might be useful, but it's again confusing.

And for keyboard:

• Arrow keys move the object in world coordinates. Not actually sure what they do in GLLara. This solution is as good as any, I guess.
• Arrow keys and alt move the object up and down. That could work.
• F keys do stuff. Ignored; Mac OS X apps shouldn't be using them.
• Number keys set camera targets. Thinking about ignoring that one.
• There is an enhancement request for XNALara to move bones with arrow keys + Q,W,E (which would, in my case, be X,Y,Z or similar). Sounds good.
• Shift as a general speed modifier? I say yes.

I'll bring this in a coherent form tomorrow.

Optional parts are not supported directly. They are sort of supported (on a mesh level), but I think XNALara also has multiple-mesh optional parts. That should be added.

This is a necessary prerequisite for #33 and #10. A user must be able to assign their own textures to an object. Necessary parts of that include:

• Texture assignments need to be stored in the model.
• Different textures need to be loaded when the texture assignment changes.
• Texture assignment needs to change when a texture is moved/deleted.

I don't think anyone (not even me) would actually use AppleScript here, but it would be a fun exercise, and I've always wanted to try it. It could also help with test automation at a high level (such as #15).

The script dictionary should represent the things accessible through the main window as closely as possible. Adding new items or subitems may be more interesting.

Right now, the name shown for a mesh in a generic item contains all the underscores, pluses, minuses and so on that are only used internally. Only the name part should be shown.

It may be useful to allow it to be changed, too.

As the title says. So I need to figure out why there is no value, and then ensure that it is set anyway. It may make sense to have a global default for all files for this parameter.

Examples can be found in the TRL levels Peru and Russia (yes I know it's Kazakhstan, but the file names all say Russia). It is not related to alpha blending; I've already tried that one.

This may or may not be related to the other level rendering bugs.

Write them out as generic format.

It is not possible to see all UI elements, in particular for the mesh view controller, with the default window size. It may make sense to embed at least this controller in a scroll view.

This affects only the current development version. OBJ files do not get rendered. Some more research is necessary to see whether this is only OBJ or all non-poseable models.

This affects both .mesh and .obj files - if there is just one bone, they don't show up on screen. This only happens in the current development versions.

That could allow for some fun effects like giant heads or hands. The implementation isn't hard; the UI will be, though, since I don't like the way it's currently handled for the item.

Currently, it's obvious to me how to use the app, and rather difficult for anyone else. Especially with #36, having documentation is essential. A readme would be nice, a complete Apple help system might be ideal, especially since most users do not look at Github.

This part will take a bit longer, but should provide some clear advantages: One can verify that all shaders work, as well as posed models and special new features (like clothes #7 , texture packs #10 , new render groups #8 ). This should make it easier and quicker to iterate on graphic-related things.

It will be necessary to have some automatic way to generate new "expected" values, because if I do change things in an incompatible way, I don't want to have to generate all expected images again.

Not sure if it's possible and useful to simply compare screenshots; OpenGL doesn't really promise pixel-perfect accuracy.

Right now, the default render parameters for OBJ files are set so that generic OBJ files don't look horrible. The result is that XNALara-specific OBJ files look horrible, and it turns out way more people use them with GLLara. So either:

1. Set the defaults to be useful for XNALara, and screw normal OBJs or
2. Have some interface that allows users to set the defaults themselves on loading. That might be in the form of an accessory view to file loading (with a checkbox), or a dialog field appearing after loading. I like the accessory view better.

One could also guess based on the existence of "vc" elements, but e.g. http://fullm8n.deviantart.com/art/Pool-environment-247031063 does not have them but still should get the XNALara-specific defaults.

I think I'll first try option 1 and then think about whether option 2 provides any benefit.

This does not have to be movement per mouse; rather, it would be nice if the existing sliders were (or could be set to) move relative to camera.

The UI for that would probably have to look wonky somehow.

If you add an item, chances are good that you want to modify it.

I can do german, although I'd like to finalize the UI a bit more before doing that. For other languages, I would need volunteers.

My guess is that this is because my choice of ambient, diffuse and specular color for OBJ files that don't specify them is wrong, or being used incorrectly.

The current workaround is to turn on all three lights.

Encountered on different Lion systems in different forms: Triangles that randomly go all over the place. Both encountered in the version where the outline remains visible (i.e. shifted indices) and in a version where the triangles appear almost infinite in size (image attached).

Those may be two different bugs.

So far, I've only seen it on 10.7, so I'm marking this as wontfix unless I find an easy solution or see it appear on 10.8, too.

Right now, some unit tests fail due to semantic changes in the mesh, and others have been disabled since exporting has been moved to GLLItem. These should be enabled again. That means fixing the tests.

In file http://fullm8n.deviantart.com/art/Pool-environment-247031063 , several textures appear all black. That file has caused previous issues, since it used 32-bit RGB (no alpha) DDS textures which weren't supported. My guess is that it has something to do with that.

Again, as described in http://xnalaraitalia.deviantart.com/journal/XPS-10-9-4-Wardrobe-Edition-349764705.

Changing backface culling is already implemented. Similarly, the different options to interpret normals should make the parts for this pointless. So it's the normal direction and the mesh smoothing operators that are the most interesting.

This will probably be put on the back burner for now.

Someone is writing it. It's not me. Who is it? The logging itself is not a bug, but it may indicate one.

To reproduce:

1. Select a lot of meshes and adjust their values
2. Change to something else, e.g. lights.

The log will show an exception because the mesh selection controller tries to access the lights as if they were meshes. After this, it is not possible to use any other side view.

In particular emissive textures, and groups 32 and 33 as described, again, in http://xnalaraitalia.deviantart.com/journal/XPS-10-9-4-Wardrobe-Edition-349764705

This seems to happen both on 10.7 (internal development version) and 10.8 (released version). Changing the camera angle or updating the poses of the model causes the app to hang somewhere in gldUpdateDispatch. It's verified to happen on GeForce 8600 M cards.

Not entirely sure how that'll look like. It'll probably involve adding some "handles" to each selected bone that a user can then drag to turn it.

XPS has a new Generic Item format with a magic number, additional attributes and, apparently, sometimes no tangents. My current support for that is based on reverse-engineering files that have it. It ignores all additional information and new capabilities. That is not optimal.

I've got documentation for this format from XPS's developer, but I had to promise not to release my implementation as open source. So this will have to be an external module (.dylib or .a) that is then embedded in the project.

(Just a reminder to myself)

They are not random, they are in the order in which they're stored in the file, but this means that they can be very different for two files that have essentially the same bone names.

An easy solution would be to sort them somehow in the item, but in the long term, I'd really prefer to use an Array or Tree Controller. I just feel that using a tree controller can be a lot of work, given the very diverse structure of data I show in the source list.

In exported images that show all solid objects, the alpha channel should be all 1.0/255. It isn't. That means formats without alpha channel will see the default bleed through, and formats with alpha channel will have holes at odd places.

A workaround is to export as a format with alpha channel (TGA works well), then delete the alpha channel or modify it in Photoshop.

The problem seems to be related to blending. I need to find some way to ensure that things with alpha=1 stay at alpha=1 and things without get set to the incoming alpha.

I've encountered this in only one file, but it is necessary to investigate this further.

Seems to be bindings related.

An example of the issue can be seen under:

http://obeywat.deviantart.com/art/HELP-349017325

The model chosen was:

http://xnamodels.blogspot.com/2012/06/juliet-default.html

The cause is unclear. A few notes:

• The model has parts with and without alpha blending, all using the same shader otherwise.
• The alpha-blended parts are rendered correctly, so it looks as if both shader and textures are loaded and generally working correctly.
• I'm specifying 8x multisampling, even though some GPUs can only support 4x (but the Intel HD 4000 isn't among them). The image here looks remarkably as if there was no multisampling.

Selecting several meshes at once (> 50) leads to noticeable slowdowns that can, for large numbers, seem indistinguishable from hangs.

Just a reminder for the milestone, so I don't forget it. New version will be 0.2.0, build 3.0 (third public release). Any until then will be 0.2.0 Beta, build 2.1, 2.2 and so on.

The way it is right now is ugly.

XNALara allows setting the background, and users might expect that here, too. I don't like it; a skydome or level is a better background, and adding things by hand is probably best done in Photoshop. But perhaps users expect it? Needs research.

Setting would happen on a per-document basis. Both colors and images are easy to imagine. It would be necessary to find some way of dealing with this on export. An "include background" option on export might be the easiest thing. Of course, GLLara already always provides an alpha channel, which was quite a bit of work, but I'm not sure how many people actually know that, and if they do override the background, they would expect image exports to include said background.

Based on the system described by http://xnalaraitalia.deviantart.com/journal/XPS-10-9-3-Broadway-Edition-338899475.

When an item is selected, clicking on selecting a bone causes an immense slowdown in the app. It also opens way too many subitems. The problem appears to be in -[GLLDocumentController _recursivelyExpandItem:], but I think the issue is not directly in that; rather in how often it is called.

Light coming from above is indicated with a negative angle. That can't be right. And it's probably a bug with the shader, but I don't want to change the light calculation there unless I really have to, since that would break existing files. It would make more sense to adjust this in the UI instead.

This needs several parts:

• UI to assign different shader, and shader name stored in model
• Default textures for objects that don't have them, and a way to assign new textures there. Possibly including reassigning of all textures. This is its own item.
• Not all models have tangents. They should probably be created automatically.
• Not all models have two sets of texture coordinates. Can the first set be re-used as a second set if necessary?
• Descriptions of shaders need to be in the UI.
• Texture binding needs to be done in a flexible way. Probably best in the order stored in the shader description, by name.

All the thor glow parts do not work because I don't have a shader. Looking at XNALara, this appears to be a more complex thing with additional sprites, and it's really not actually necessary for most things. Still, it would be nice to have this, just for completeness's sake.

This means most parts of the model don't render. Ought to be an easy fix, I just can't be bothered right now.