robcat2075

I think it's a bit too soon.

Congratulations Kualrobi! That will be a fine mascot!

Send me a sample of the data that isn't working.

Well, that is creepy!

Every time this comes up I say "get me a copy of the file format you're trying to import and we can make a converter" but no one ever does that. There are only seven possible pieces of data in camera tracking... Camera position in XYZ space, Camera rotation on XYZ axis and maybe Camera lens focal length. Worst case, you have to convert units and trade one axis for another... spreadsheets are made for that. Jason, that person asking about importing camera tracking needs to be specific about what format his camera tracking is in. If he doesn't know then he's probably hasn't done any.

I seem to recall the Syntheyes (?) program produced A:M Camera animation from tracking live footage. In general, if we had a documented example of the camera motion format, it should be possible to make a spreadsheet to convert it to A:M motion.

I tested a few simple scenes... -It seems to create one image file per patch if you choose "Polygon", but two identical images per patch if you choose "Patch" -The images do not include shadows or AO, even if "shadows" is checked. -The images seem to be light information only and do not include surface colors or textures. Here's a problem with "baking" lighting I think... Each side of a patch can shade differently depending on which side the light hits, but an image on a patch appears on both sides. If that image is supposed to be the baked lighting which side does it represent? I suppose there could be a rule that only the normal-positive side's lighting gets baked and you'd have to make sure you have no single thickness patches visible to your camera

That option is not available to everyone. Only Alpha/Beta testers? The latest reports section most of us have access to is v18. You're right about that. If Elm wants to write the report now he could do it in v18 and I'll make a note to bring it to Steffen's attention, or... he can wait until v19 opens up since Steffen probably can't jump on it immediately anyway.

go to hash.com/reports You may need to get a password from Jason if you don't have one for AMReports already. For "Project" choose V19.0 For "Severity" choose "feature" Explain what you want, why you want it and point out what is already there in A:M

You can move the Kleig Light farther away so it lights your whole scene. We did that for TWO so we could use faster-rendering z-buffered shadows instead of ray-traced Sun lights. If you make its cone angle small and move it far away it will appear like the parallel rays of a Sun light.

I gave Matt's practical light version a try with a Material on a small grid in front of a light It does work. You'll need to set Transparency somewhere between 0 and 100% for the two Parameters of the Combiner and experiment with color combinations. If you want to use a colored light instead of a colored material, you will need to set the light color in the Chor You'll also need to set your Kleig light to Ray-Traced. Z-Buffered won't properly cast partial shadows through partially transparent objects. There probably is a small render time hit in having to use a Ray-traced light but it was fairly speedy none-the-less and this method doesn't lose the material's animation when the PRJ is saved.

He's a cutie!

I have multiple computers around the house but only one works.

Yes, GL is felicitously on both Mac and Windows.

OpenGL and OpenGL3 are the only options. Your video card supports up to OpenGL 4.4 so 1 and 3 should be no problem for it. Direct X was another option that is no longer supported.

Apparently there's some sort of cloud problem (not specifically A:M related) to be aware of... Maybe Be Careful with OSX Sierra

I've been experimenting with this. I can animate setting on the material and it renders as expected... CausticVolTest000.mov but.... when i save and reload the PRJ the animation doesn't work anymore. Seems to be a problem even back to v17 For now the workaround may be that you have to save your PRJ BEFORE you add the material to the light. Load the PRJ, add the material and redo your animation settings, which you have written down before hand. Of course, Netrender isn't an option with this scenario. A bug report may be in order.

It seems you can also drag a Material onto a light, which would save you the intermediate step of rendering your caustic pattern into an image sequence.

I believe the process is to drag an image onto a light.

Hey, those are wonderful entries! I'm glad we got to pick three because picking one would have been impossible! Historical trivia: I recently read for the first time an explanation about why the US Presidential election was originally a "pick two" contest in the Electoral college. Apparently, in the time before political parties existed, it was presumed that regional prejudices would be so great that no one person could get a majority in a "pick one" contest where every elector got only one vote to pick their favorite. It was hoped that by making every elector vote for an additional second person that the combination of first and second favorite votes would make one person rise to the top as an acceptable consensus choice among a majority of electors. The next highest vote getter would get the VP job. However that mechanism broke down when parties formed and explicitly nominated both President and VP candidates.

I believe this was a feature created for that studio that did "Tak" and other games. I suspect that these files were meant for use in their game engine somehow and that getting them back into A:M was not a necessary part of the pipeline. If it actually does record the lighting into a bitmap, perhaps not much further work is needed to complete the circle and a feature request to Steffen would get it done.

It looks that way on straight lines but maybe not on curves?

Yes, let us see how your project progresses!

I hope it's a pick-three vote.

Here's what is stored in an action that was created at 24 fps MatchName=X 1 0 0 ( 0 seconds) 1 1:0 0 ( 1 second + 0 30ths) 1 1:7.2250 0 ( 1 second + 7.2250 30ths equal to 1 second + 6 24ths) 1 1:15 0 ( 1 second + 15 30ths equal to 1 second + 12 24ths) 1 1:28.3375 0 ( 1 second + 28.3375 30ths equal to 1 second + 23 24ths) I presume that writing the time as seconds + 30ths was deemed to be more human readable than a pure seconds and decimal number.