-
Posts
21,575 -
Joined
-
Last visited
-
Days Won
110
Content Type
Profiles
Forums
Events
Everything posted by Rodney
-
Two (or more) A:M Users can collaborate without concern for their files being compromised. This is because the URL (DAT Address) is said to be unguessable and the data itself is encrypted during transfer. So, only those who have access to the address can access the data stream. https://beakerbrowser.com/docs/tutorials/share-files-secretly.html
-
Files can be kept in sync by 'listening' for changes to directories or files: This notifies everyone that they need to refresh their content. After the file is updated success https://beakerbrowser.com/docs/tutorials/listen-for-file-changes.html
-
I'm currently researching how detrimental it is to serve DAT from external drives. I know network drives take a hit because the data has to be written twice (presumably once to the main computer and then once to the remote client). It seems to me that external drives might take this hit also.
-
Wondering out loud.. How many folks would pay $99 a year for the ability to move Animation:Master around from computer to computer (i.e. activate and deactivate A:M as the need arises to move the license just by logging in to a website and adjusting the license)? I'm not suggesting this would be feasible (or even particularly possible) and very likely it would not but I still cannot help but wonder.... would that be worth an additional $20 per year?
-
That would depend on what software provider they use. If they are using what I think they are that might not be the case. Here are some general guidelines: While there are certainly no guarantees in this guessing game that second bullet point would likely have us covered. There are a lot of assumptions here... such as sticking with the same company. Moving to a different license manager could be expected to break stuff. But that's where you maintain the old, add the new and wait until all the users under the old scheme expire.
-
Rusty, By all means join in the fun. If you download the Beaker Browser (link above) and enter the following address you should be able to see two models and one action: dat://8ddfac3988fd0bd8c654af3785951f174d15c9baadb60e241a67590c698ed642 As soon as someone launches the Beaker browser they can also set up distributed secure servers of their own (and remove them when no longer needed). What I would very likely do as a Proof of Concept would be to publish the data from the AM DVD for others to Fork to their own DAT servers and somewhere in that mix there would be a place where we would mix all of our files. For instance, I might render something out of A:M to a DAT Render Folder that other folks could immediately use in A:M. Likewise, we could have a Master Project that everyone would add resources into.... a kind of 'one Project to rule them all' approach. For testing purposes of course. I was also thinking of running a challenge of sorts called '48 frames' where a group of A:M users all contribute in DAT time to fill those 2 seconds worth of frames with (theoretically) high quality content. The underlying premise being that if 48 seconds can be filled then productions of larger size can be completed in similar ways. I've experimented with a number of other things but right now I'm mostly interested in just making the first connection. If there are problems with that then it doesn't matter much what we can dream up... it won't work anyway. DAT servers can serve up secure and secret transfers so don't release any DAT address out in public that you want to keep private! Who knows... perhaps this could be the resurgence of that ages old plan to create an Animation:Master digital magazine. That'd be sweet. Those involved in creating the issues would create in private and then when ready to publish the proper DAT address would be released.
-
If they will share the info that'd be great. It's generally not going to be good practice to give out that kind of information because not knowing what type of security is an extra level of security that keeps folks honest. But usually this isn't secret. It's just not wise from a security standpoint to share it. Someone who wants it that bad will find the information. I think I know what activation management software they use but... not my info to give.** It's possible that Hash Inc might be ready to move to another activation methodology either now or in the future. If it makes good sense to make the move given all factors involved, they will. If not, they'll put that idea back on the shelf. Keep in mind that no one here needs to know this stuff other than for the purpose of our curiosity and considering what we might have to use to activate A:M in the future if anything should change. We are easily convinced. It is Jason and the powers that be at Hash Inc that need the information so they can make informed decisions. It is their decision to make. Disclaimer: If Hash Inc decides to make licensing more restrictive than it currently is I reserve the right to be very irritated. **If the licensing software is what I think it is the capability you propose is not an option without incurring more expense. That expense would need to be passed on to the users.
-
No Sir, not unless Dropbox has changed significantly of late. II don't have a point by point comparison to provide but pehaps the root difference is that Dropbox is maintained on a third party server. This would provide a means to securely host and share with only two computers and I suppose technically at least one ISP (because the computers need to connect via internet. There are some other technologies coming online that will handle local networks but I'm wanting something that I can host on my computer and others can access directly. Other parties don't have to do the same thing although they can. A key element is Distributed Dataset Syncronation and Versioning (DAT) Here's a whitepaper on it from May 2017: https://github.com/datproject/docs/blob/master/papers/dat-paper.pdf Having said this there are also ways to publish this data in similar ways as http protocols and files can always be mirrored on sites like Dropbox. Third party servers would be the fall back but not the environment for the creative side of things. For those that want to investigate the easiest way to get up to speed would be to download the Beaker Browser and follow instructions on how to set up a DAT server. https://beakerbrowser.com/ For more info see: https://beakerbrowser.com/docs/
-
Are there any brave souls out there willing to help me test some peer to peer file sharing? I'm looking for one or two people to help me test the basic process. The underlying idea is that of distributed computing where files are shared from my computer directly to anyone with the address without need for a middleman server. If they so desire they can also share files as if they have their own server. I'm leaning toward this approach for the next round of A:M Extras and other productions but it really needs to shown to work well first. I think I can only use WIndows users only at this time. Later testing should expand to Mac and Linux. For those too shy to post their interest here please feel free to email me at: rodney.baker@gmail.com
-
As an aside... It would be nice if A:M could be forgiving of extra entries such as ... and extra space so that in addition to generally compatibility comments could be entered inside that would not immediately corrupt the file. Update: Actually, A:M may already be forgiving of the and extra spaces. As long as the first line is removed. And of course the file cannot be named with the extension .xml but needs to be .prj. Also, I can see where leaving files unembedded can be advantageous when working with A:M files as xml assets. That simplifies things considerably at the local level.
-
Just as a general curiousity, here's what an empty Project file looks like in JSON format: When converting back (to xml) there are a few formatting things to watch out for: Extraneous text in red. The extra space needs to be removed as well.
-
It's an option worth exploring. I'm not sure what their software activation suite allows. From the site: Either you are paying a lot more for A:M that I think you are or those folks are giving you a very nice discount over the advertised price. Edit: if you were a user of Imagaro Z when the program changed hands and became graphics tracer I see that you did get a sizeable lifetime discount. That 50% discount would make the math work (somewhat) but I don't think that can count as the true cost of the product.
-
You are getting very sleepy...
-
Yay! Someone is using Layers in A:M! Thanks for sharing that tip Tore! With Layers we can also adjust some of the settings to alter the look and feel. For example: Cranking up the ambiance intensity. And not that you'd use it in this production but changing the ambiance color and then the intensity of layers can yield some interesting animated effects. Another neat tricks with layers that your current style makes me think of are things like shadowy figures moving in the foreground or animated vignettes or atmospherics (for instance some noise/haze placed both in front of and in back of the characters in a scene. And as you say, because they are prerendered they re-render very quickly. I will add: A few of the downsides to using Layers vs Patch Images (i.e. images assigned to a single patch ala Layers) is that with Layers only one image can be used. With patches we can also skew and bend the patch into different shapes whereas Layers are confined to a rectangular plane. Where the images are straightforward planar images it's hard to beat a Layer. I'd have to check but I think Layers produce much better shadows (for the light shining through transparent/alpha areas.
-
Ah! Yes, that's the ticket! Sorry to see he's gone to the dark side. He always seemed like such a good guy. That was a great movie. I need to watch that one again ASAP. That and Abbot and Costello go to Mars... or was it the moon... They don't make 'em like that anymore.
-
That guy is obviously up to no good. He's even got a black hat. Dastardly. He definitely looks the part... and I'm sure I've seen him before.. maybe on Bonanza! Looking very good Mark! Aside: This is probably by design or maybe it's just the angle... his forearms look overly long. Maybe it's because his knees are bent and that makes his lower legs look shorter? The lighter color from the forearm to hand on left arm might be placing extra emphasis there also. If he's got a boot gun any extra length in the arms would certainly help him get to shootin' faster. Press on. Press on!
-
Ohoh.... I was walking away from the computer and more thoughts came to mind on subjects I've long been interested in. There is a general rule in computer processing that if and when control must be taken away from the user that control should be given back at the earliest possible opportunity. Now, let me insert a disclaimer... this is not a critique of A:M's renderer taking over and holding on for the entire length of a render. That is simply part of the larger equation. Yes, optimally, control should be given back immediately. How this is best accomplished with A:M is through Netrender... so... mostly a non issue. What I think represents considerable room for improvement relates to internal renderings in A:M. Not to the renderings themselves but to the experience we have (or potentially could have) while rendering. When the task of (internal) rendering is deemed important enough to launch a rendering session it is that experience that must be optimized and enhanced. How can the experience of waiting for images to render be enhanced? In many ways, the first of which is to maximize real estate and take full advantage of the rendering interface. It's like an old TaoA:M guru saying, "When I am rendering I am rendering." So, the first priority would be to maximize the render panels so that off limits areas (those that cannot be accessed while rendering) are not seen. When I see my Chor window... right there... just out of reach.... I want to get back to using it! The second priority would be to inform the user of what it is they are rendering (or have rendered). This can take on many forms and currently there is useful information to be found... rendering times, render locations. It would be useful to see the settings I set for the render. It would be useful to see information about rendering (ala Info Properties). Then I might say... "Hmmm... next time I don't think I'll do that" or "Aha! That's what I was missing!" *** But right now we mostly just wait. This isn't to say that waiting for a render is a bad thing! Everyone needs to take the occasional break. So the question might be... how can we better engage the user during that quality time spent rendering? *** In time images created using specific settings could be presented to the user so they know what to expect. This is actually the underlying premise of the Presets and the iconic images that accompany them. A full screen Render Panel might leave the Presets panel active so that the settings could be examined. Returning to thoughts mentioned in the last post there might even be a means to compare the last Preset (last render setting) with the current preset (current render settings) so we get a clearer view of what we have changed.
-
I ran across several things related to some of the above musings and want to add one here because it's trivial enough that I'm sure to forget it. The thought is that now that A:M is set (by default) to save a Project just prior to rendering... It could (at least theoretically) be made to compare that saved Project to a Previously saved Project. The difference between those two Projects could therefore inform the renderer if anything of significance has changed. Some classifications and tests would need to be trialed but this coupled with channel data could narrow the field considerably with regard to the emphasis needed for the renderer. I'm trying to imagine what success might look like and I confess I'm not seeing that clearly. I suppose we could start with a dumb user like me who just simply forgot he just rendered a Project and tried to render it again. This might be Class 0 where nothing has changed and since nothing has changed the previous render is fetched and presented. I will admit that case would be very rare. But Case 1 might be where only one thing has changed... say... last time I rendered out to TGA quality but this time I want to render out to VGA. So, although no data in the Project itself has changed the renderer's requirement has changed. The renderer, knowing that only the desired resolution has changed might prefetch the previous render to display as a preview and update that upon the completion of each newly rendered frame. A tagline would let the user know the image being displayed wasn't final. Would such a thing be worthy of code? Probably not without many other optimizations thrown in for free. But this suggests three basic categories of interest with regard to change optimized renderings: 1. Iterative Changes: The Project File differences (current and previous... for additional optimization the user can overwrite what is considered previous) 2. Internal Changes: Change occurring in Time and Space within the Project itself. The renderer knows that of 15 objects in the scene in front of the camera only one object is recording any movement therefore that object and what it interacts with receives the priority. 3. Renderer changes: In this category data is collected and improved upon with every rendering. Two primary values are recorded prior to rendering and those values are weighted after the render. The first value is determined (in boolean fashion) by what options are selected for rendering. Let's say that all of the values of the settings equate to 128 because almost all are turned off. This then is the ID of the underlying settings that drove the renderer. Subsequent renders are then compared first to other renderings with an ID of 128 and then to the those of other IDs. The second value is the weighted value that can be changed by other factors to include data derived from Cateogries 1 and 2 as well as results such as average render time per frame and over all render time. One of the things this approach can inform is that of determining a desired render time before launching a render. Let's say I want A:M to spend all of its resources for the next five minutes to render my scene. Using the data collected from previous rendering it can suggest settings that will be optimal for me. I can overwrite those but that weighting would have to be balanced somewhere else... or I'd have to increase my estimated time for the rendering. And this is also where composting and masking might can come into play as well as split rendering where I choose what objects in the scene are truly necessary. As I (optimally) want the results of my rendering back in 1 second per frame this time around.. I'm willing to sacrifice a few things. And oh by the way... I know for a fact that these five frames are going to be exactly the same so... I'll indicate that as well via the enhanced Stepping options. Okay, I'll stop there. I was only planning on writing two sentences. And I'm not sure I go those in... .
-
Nice one Robert! That's a winner!
-
Very nice!
-
Yes, the activation code will only work on the specific computer you activated it on before (assuming was used in the first place and not awaiting initial activation... then it can be activated on any computer.). Locate the other activation code and all should work fine. (That should also be in the Hash Inc store) To get the activation dialog to appear you may need to remove the master0.lic file from the install directory. You don't have to delete it if that is a concern... just move it. The process of activation will create a new one.
-
I think you've probably accomplished what you set out to do for his one. Does the guy at the bottom of the screen sitting there without a shirt in the second shot count? (I assume that must be your cameo in the film) My only suggestion would be to add some post effecting to make the style look like black and white (or sepia?) to give a sense of old timey film or western flavor. I've got something of an example rendering now.
-
No, that'll work fine too. you just have to activate that install. Although, I usually do install a minor update into the same location. It's okay to install into another folder... but you'll need to either: - Use your activation code to activate the new installation. - Copy the license file (master0.lic) from your other directory into the newly installed directory. Of the two the second is considered by most to be the easiest. I assume this is mostly because folks don't know where they can find the activation code which is maintained at the Hash Inc store if you purchased online. As this is the same computer the initial license was activated on both methods should work fine. This is the same way you would activate the 32bit release of A:M and run it side by side with the 64bit. Of course, they will automatically install to different locations whereas to install subsequent (or previous) releases to other locations we have to do that manually by telling the installer where to install. For instance, we might want to install the 32bit release in order to render out to .MOV format... as that isn't available via the 64bit install. Installing to different locations can sometimes be the only way to get at features that have evolved themselves right off the map or been replaced altogether. By installing to different locations all features can be accessed from whichever release is needed.
-
Dan, You are very good at translating characters from drawings to 3D. (I've likely said that a few times before but it's worth repeating) Bernie has made the transition thus far quite well!
-
Nice. I'm impressed that Intuit went to all that trouble! Almost makes me wanna do my taxes. I can see why you like the street shot. The good news there might be that you only need to build the facades facing the camera.