questions (including BTP animation support)

[hisprofile]

Sorry to bother you again, but i have a few questions.

1. is .bdl supported? i did see you post that it does, but i could not find any .bdl's in the importer.
2. will .btp texture animations be supported?

[niacdoial]

Sorry for the late response, and the probably disappointing answers. 1: I don't really get what you are saying in the first question (I can see the bdl files in the file explorer part of the importing UI) 2: I think it will have to wait until late October, so that I can also create an adapted version of BleMD for blender 2.8 at the same time (since both things demand a lot of reworking around the material part)

[niacdoial]

BTP texture animations are nearly impossible (or at least very impractical) to import into blender 2.7x, because dynamic texture switching is simply not possible. I have an idea for how to work around this, but it is very hacky, and I don't have a lot of free time to spend on BleMD lately.

[edbefee3-3888-462a-9411-741b7e9eb54e]

Is it possible now?

[niacdoial]

I don't think so. BTP texture animations require swapping textures in and out, so unless you find a way to animate the "image to link to" property of an image texture node, or do something that could replace that, that's going to be difficult.

[edbefee3-3888-462a-9411-741b7e9eb54e]

what about the factor for a MixRGB/Mix Shader? in mix mode setting it to 1 would only be tex1, while setting it to 0 would be tex0

[edbefee3-3888-462a-9411-741b7e9eb54e]

and a mix factor can be keyframed

[niacdoial]

yeah, but this would mean adding every (sometimes >100) image textures to every shader, and wire every one of those to every point where an image is called in the shader, and then keep track of the resulting (sometimes >5000) mix nodes somewhere. needless to say, it's way too ugly.

and what if I look ahead to see which image can be needed where? That would also be ugly, because you would need to somehow look into the BTP files in the middle of building a given shader every shader at once. Because you need information from the shaders in order to understand what the BTP files mean.

so, no. I'm not doing that. sorry. Maybe I'll find a way to dump the results of the animations into human-readable text files, so you can fix that after the fact

[edbefee3-3888-462a-9411-741b7e9eb54e]

actually, what about image sequences?

[niacdoial]

uuuh… actually it would work, but it would mean copying an image for each frame of each btp animation, so a huge waste of space. Also it would mean that the blender file couldn't be self-contained anymore, nevermind trying to export to another piece of 3D software. Sounds more viable, but still far from clean enough, for now.

[edbefee3-3888-462a-9411-741b7e9eb54e]

you can actually use offsets to only have each texture once

[niacdoial]

I don't think image sequences allow for enough flexibility to say "this image for N frames, than that image for M frames, then a third one for L frames, etc…" I don't think they even support having the middle image show up for more than a single frame

[edbefee3-3888-462a-9411-741b7e9eb54e]

using animated offsets, you can have any image display for n frames

[edbefee3-3888-462a-9411-741b7e9eb54e]

((o-frame>-n)*(o-frame))+(o-frame<-n)*(o-n) n being the amount of textures o being the texture offset

[edbefee3-3888-462a-9411-741b7e9eb54e]

you can use a custom property for o so you can keyframe it

[niacdoial]

oh, I see what I can do (even though I don't know what that equation means) still means creating n_btp_files×n_images_per_btp_file extra images, but it's better than n_btp_files×n_frames_per_btp_file

[edbefee3-3888-462a-9411-741b7e9eb54e]

actually, you can just assign each texture a number (and ignore clone textures) so it's just animated_textures and then make it start at a non-zero offset

[edbefee3-3888-462a-9411-741b7e9eb54e]

btw that equasion can be broken to two parts first part: if offset - frame is bigger than -texture count, then use offset - frame, and then you add the second part: if offset - frame is smaller than -texture count, then use texture count - offset the second part is because if the current frame is higher than the animation length, then it uses the last frame. if you make it cyclic, it just o-frame%n since it wraps back after n is reached

[niacdoial]

I don't think this is how it works, since the image sequences need to have all of their images on disk. and er… even if I understand that equation properly, setting the start_frame property to the number_of_frames property of the image sequence, it completely ignores the frame number in blender, and the offset directly corresponds to the identifier of the image loaded

[edbefee3-3888-462a-9411-741b7e9eb54e]

that's a driver for frame_offset, not a value for start_frame

[niacdoial]

yet, but I was saying that you can remove blender's internal frame number from the equation by setting the image sequence's start_frame to its frame_count, which simplifies everything by a lot.