Luuk Steitner
-
Posts
623 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Luuk Steitner
-
-
Enter the activation key only on the computer where you want to use it
-
Can you really see through them? Look at the UV-Editor (go to the decal, rightclick on it and click on "edit"...
I would say it is a antialising-effect/recalculation-effect from the decal, not something from the model itself.
Just go to your 2d-applikation and make a clean new map. Now try it again.
*Fuchur*
I rescaled the image in Photoshop. I tried 50% and 25% both same problem. It's hard to tell of whether the UV map is correct or not because the UV editor show a very low quality version of the image. OF what I see the patches are bigger than the decal, but it looks the same with the original decal that doesn't give seams.
If surface baking is using tiles, then resizing them will cause areas around the seams to combine and "muddy". To resize them effectively, you'd need software that scaled the inside of each tile while respecting the boundaries.Do you know such software? If it doesn't exists yet maybe it's worth the effort to make it. Or we should just ask Hash to let the user decide in A:M how big the image should be. Since there already is a function for this in A:M it now should only be accessible by the user.
-
You should be able to resize the image of the decal (texture) into any size you want, as long as the ratio isnt changed.
The uvs are saved with the decal, not with the image in anyway.
I did that with many decal-images before and it always worked fine. (You may have to reload the project so)
You're right, is does work. But not completely satisfying. I did a simple test with a resized baked surface decal and there are seams showing where the splines are.
I wonder what causes this. In the real time view the seams are so big that you can easily see through them.
-
I have just installed the V15 web subscription to try the surface baking. I noticed the size of the baked image is relative to the size of the model.
I'm working on a large and detailed theater at the moment and would like to have control over the baked decal size, because now the file sizes will get extremely large. Unless I make the model very small, but I don't want to do that. Would it be possible to make them smaller afterwards without affecting the UV data?
I could of course save them as JPEGs But I wonder, will that still consume the same amount of memory when rendering? I assume the total images are loaded into the memory as bitmaps during rendering. Or am I wrong?
-
Wow, that looks great! I like it
-
I have just launched version 1.1
Not much changes yet but two important fixes that shouldn't wait too long. I'll try to get the 2D exporter done a.s.a.p. and if things work out like I expect I have a nice surprise for A:M users in the next upgrade... (I'm not telling till I'm sure it will work
) -
I'm happy you have figured it out Paul
It would be nice if Hash made the action baking overwrite all keyframes. Would that be a feature request or an error report?
-
I think I have a solution for you, don't give up yet.
Make the parts where the dots are showing a separate group and give it it's own toon settings. Setting the toon lines thickness to '0' for example.
-
As you take a look at the close up on the time line the jitter is very obvious, especially on the blue spline. I don't know why this happens but it definitely looks like a baking error. Time for a report I think.
Do you still think baking is a good solution for the actions (if it worked OK)? Maybe we should forget about this and just same each action and BVH file with explicit names so it's obvious which action / BVH contains a certain clip.
-
Can you show a picture of the rotation curve for the head bone in the time line for the baked action?
And, can you email me the BVH file so I can take a look at it? If there's a problem with exporting the lip motion I need to find out what's causing that.
-
If those areas are considered to be edges maybe a higher resolution displacement map would help, or maybe lower.... Maybe it's worth a try.
-
This image is reduced in size. Are the black dots on the original render perfect squares or are they smooth? If they are squares it's a render error. I have had such problems in v14 some time ago and I was hoping it was solved by now.
It might be something else tough.
-
Ah, yes! Thanks, Luuk.
Any clues as to what is happening here? :
This was a test where a BVH file was baked to an action from the choeography. The action was then applied to this model, (which uses a copy of the rig that I constrained the BVH data to before baking).
This jitter was not apparent before baking.
Maybe the jitter is caused by the error reduction while baking the action. You could check the spline shape of the rotation axis of those bones. If the splines are poking out between the key frames you know where the error is. I'm just guessing, I'm not sure if this could happen and if it does I think it is not supposed to happen...
-
Can someone explain what RotateW is?
I'm also quite puzzled by the feedback that I get from A:M when I click on any of those transform channels for the "jaw" bone. If I click on any one, from Transform Scale X to Transform Translate Z the jaw bone is highlited in yellow. But if I click on Transform Rotate X to Transform Rotate W a finger bone is highlighted.
The rotate W is part of the Quaternion rotation and compensates the rotate X so the magnitude = sqrt(w2 + x2 + y2 + z2) is always 1.
I don't know what causes the strange highlights.
-
How long is your action? Maybe you can give it a try with short action (a few seconds) and see what is baked.
-
Has anyone had any success baking actions in A:M14c? I just keep getting exception 001 followed by a crash.
Any suggestions?
Same problem here (also v14) Time for a report I guess.
I does work from the chor for me.
-
First, ZignTrack exported a bvh with a frame interval of .034483, which seems off. My original footage was NTSC 29.97 which should yield a frame interval of .033333, and if I hack the bvh and change the interval to .033333 it imports correctly into my 30 fps A:M project.
I found the problem. The FPS is calculated by the rate divided by the scale (that's the normal way to do that from the AVI params) but those values are integers and in the programmed code therefore the result also was an integer. So when the result must be 29.97 it appeared to be 29 I have modified the calculation method and the FPS is calculated correctly now.
I'm planning to upload the next upgrade this weekend. Can you wait this long?
-
First, ZignTrack exported a bvh with a frame interval of .034483, which seems off. My original footage was NTSC 29.97 which should yield a frame interval of .033333, and if I hack the bvh and change the interval to .033333 it imports correctly into my 30 fps A:M project.
Thanks for the info. I'll try to find out what causes this and fix it.
EDIT: Wait, at 29.97 the interval should be 0.0333667 in stead of 0.034483. So it's wrong, but not like you say. An interval of 0.033333 would mean 30 FPS, not 29.97
-
Maybe I should clarify. How would you set this up in AM...and "use the premade setup" isn't really a helpful response. Is there a thread on how to rig a face in AM?
You could take a look at the Squetchy rig wiki. There are several tutorials there. You don't have to use the Squetchy rig if you don't want to but it will give you an idea how you can rig a face.
Also, you don't have to use a face rig that controls all facial features. You can use the BVH rig to drive muscle poses as well. At the tutorial page there should be plenty info about this.
-
I did forget about A:Ms mocap setting, that might be the trick, or at least part of it.
The eyelids are driven by the Zign track bvh. The lower lids are driven by the sneer, and the upper lids by the eyebrow.
I wonder if the A:M MoCap settings are involved for BVH files. I'll have to test this.
That's a great idea, controlling the eyelids with the sneer and eye brow features. I will add more features in a future upgrade so you'll have control of all facial features. Was it easy to stick markers to your eyelids or did you use special markers for that?
-
Woohoo, I finally had time to get Zign Track up and running. I am attaching a qt of my first successful test.
However, I had an annoying problem. The BVH exported from Zign Track was not the same length as the sound track from the same video. The BVH seems to get longer. For this render I had to rescale it to match the sound. I can't figure what the discrepancy is, I thought it might have to do with A:M operating at 30fps and video operating at 29.97 as that was an issue with syntheyes, but so far that doesn't seem to be it. Is anyone else having these issues?
Also, and probably related, the keyframes in the BVH import with a spacing of less than a whole frame. This seems wrong, as the video was tracked on whole frames. Does the BVH file specify a frame rate or is this an A:M importing issue?
Any thoughts will be appreciated.
Ben
The frame rate specified in the BVH file is the same as the frame rate of the video you loaded in Zign Track. I don't know what's causing the key frames in A:M to be shorter than one frame. I have had such an issue before (not with BVH) and solved it but that's a long time ago and I don't remember how I solved this back then. If you email me your project file and the BVH file I can take a look at it.
Your test looks pretty good though but in one part the mouth hardly moves while you're talking. Was that like your video or did you smooth the mouth too much or something?
-
This looks like a great app. Since it's bvh it can work with pretty much anything. My question though is, how would you rig something like this up? I'm in Lightwave 9.
Thanks guys!
rez
This forum is for Animation: Master discussion only so a Lightwave thread would be a bit misplaced. I don't know how it's done in Lightwave. I think you should start with looking for a tutorial that explains how to handle a BVH in your app. Or, buy Animation: Master
-
I've heard from a couple of folks who can't download or view this file. If you've tried and it won't play, let me know as I'd like to figure this out.
One guy gets an error message that he's missing some component (probably a codec) in his QT software, and another friend gets the blue Q logo but no download. Both *claim* to have the latest QT software, which I can't check. But if you've tried and failed, then given up, let me know what behavior you're seeing.
Thanks!
If one gets an message about a missing component he does not have the latest version of Quicktime. If one only sees the Q, it's just not downloading or taking a long time to download.
-
Luuk what I have seen is outstanding thanks. I downloaded the trial and I am getting an EAccessViolation message while starting the program. I am running XP Pro on a Athlon 3700 with 2 Gigs of memory. Any suggestions?
Oscar
Please send bug reports to support@zigncreations.com Tell me if the program itself is showing or not.
Decal quality
in New Users
Posted
Decals are always shown in low quality in the real time view. When you render they look normal.
If you want to paint your models, A:M Paint would be the best tool to do this.