|"Space license please..."|
|"Space license please..."|
Wednesday April 23rd 11/10 central time (8 on the west coast) To subscribe – After you complete payment click “return to Rigging Dojo” and then “register” with FirstnameLastname format. …
The post Rigging Dojo’s Artist in Residence (AIR) : April – David Bokser appeared first on Rigging Dojo.
The goless library https://github.com/rgalanakis/goless provides Go programming language semantics built on top of Stackless Python or gevent.* Here is a Go example using channels and
Select converted to goless:
c1 = goless.chan() c2 = goless.chan() def func1(): time.sleep(1) c1.send('one') goless.go(func1) def func2(): time.sleep(2) c2.send('two') goless.go(func2) for i in range(2): case, val = goless.select([goless.rcase(c1), goless.rcase(c2)]) print(val)
While I am not usually a Go programmer, I am a big fan of its style and patterns. goless provides the familiarity and practicality of Python while better enabling the asynchronous/concurrent programming style of Go. Right now it includes:
reflect.Select, since Python does not have anonymous blocks we could not replicate Go’s
gofunction (runs a function in a tasklet/greenlet).
goless is pretty well documented and tested, but please take a look or give it a try and tell us what you think here or on GitHub’s issues. I’m especially interested in adding more Go examples converted to use goless, or other Go features replicated to create better asynchronous programs.**
*. goless was written at the PyCon 2014 sprints by myself, Carlos Knippschild, and Simon Konig, with help from Kristjan Valur Jonsson and Andrew Francis (sorry the lack of accents here, I am on an unfamiliar computer). Carlos and myself were both laid off while at PyCon- if you have an interesting job opportunity for either of us, please send me an email: firstname.lastname@example.org
**. We are close to getting PyPy support working through its
stackless.py implementation. There are some lingering issues in the tests (though the examples and other ‘happy path’ code works fine under PyPy). I’ll post again and bump the version when it’s working.
|The print stands at 120mm tall, and is printed in the Fine Polyamide (Nylon) material.|
|The render of the model from ZBrush.|
The phrase “results are not the point” often confuses people new to Lean thinking. It confused the shit out of me, not having really understood it even after my first few books. This is a shame, because it’s such a simple thing.
On Friday night, Danny got really drunk, coded a game, and the game was a hit. Danny did this again the following Friday, with the same results. And once more that third Friday.
Jess codes on sober Saturday nights instead (still drinks on Friday). Jess programs a game, and it runs poorly, crashes often, and isn’t fun. The following Saturday, Jess makes a new game, which runs fast but still isn’t fun and crashes often. That third Saturday, Jess creates a new well-performing, fun game, though it still crashes.
Would you bet on the long-term success of Danny or Jess?
Clearly, the better bet here is Jess. Jess has discovered a process which can be continuously improved. There is good reason to believe Jess will eventually create reliable success. The fact that Danny has been successful three times is basically irrelevant, since Danny’s process is totally haphazard.
This is the idea behind results are not the point. Focusing on the results, and not how those results were achieved, doesn’t improve anything in the long term. The point is to create a repeatable, empirical, continuously improving process. If we can create a reliable, successful process (which here includes culture and practices), we can get reliable, successful results.
And with it, the Python API!
Which comes with something really interesting now… PySide 2.1 is built-in! Really cool
Anyway, bookmark this URL, you will probably need it during the next year: http://help.autodesk.com/view/3DSMAX/2015/ENU/
To subscribe – After you complete payment click “return to Rigging Dojo” and then “register” with FirstnameLastname format. Hi All, Chad here. Well GDC and several production milestones bumped out …
The post Rigging Dojo’s Artist in Residence (AIR) : April GDC Wrap up appeared first on Rigging Dojo.
I finally managed to get the viewport grabbing to work with python only, no hacks using MaxPlus.Core.EvalMAXscript(). More or less It’s working for the standard viewport.getViewportDib() equivalent in Maxscript, I still can’t figure out how to grab it directly from the GraphicsWindow (gw.getViewportDib()) to get a clean viewport snapshot without any overlays like gizmos, etc. This method works only in 2015.
Long story short, I’ve updated the YCDIVFX MaxPlus Packages in github and even added a new package called maxhelpers where I will put code that will be reused across all other packages.
Here’s how the code looks:
def ActiveViewport(self, filename=(MaxPlus.PathManager.GetRenderOutputDir() + r'\default.jpg')): """Grabs viewport to a file on the hard-drive using default viewport size. :param str filename: a valid path to an image file :rtype: MaxPlus.Bitmap """ # Create storage storage = MaxPlus.Factory.CreateStorage(BitmapTypes.BMM_TRUE_64) # Create BitmapInfo bmi = storage.GetBitmapInfo() # Set filename bmi.SetName(filename) # Create bitmap to hold the dib bmp = MaxPlus.Factory.CreateBitmap() # Viewport Manager vm = MaxPlus.ViewportManager # Get active viewport av = vm.GetActiveViewport() # Grab the viewport dib into the bitmap av.GetDIB(bmi, bmp) # Open bitmap for writing bmp.OpenOutput(bmi) bmp.Write(bmi) bmp.Close(bmi) return bmp
To grab and display the bitmap in max you just need to do this:
bitmap = grabActiveViewport() bitmap.Display()
Hope this is useful!
In Maxscript! I’ll just leave it here as a reminder and hopefully it will be useful for you too!~
( assembly = dotnet.loadAssembly "Autodesk.Max" g = (dotnetClass "Autodesk.Max.GlobalInterface").Instance inface = g.CoreInterface activeview = inface.ActiveViewExp print activeview.Hwnd )
|This is a single cmds.text object with it's label property set to an HTML string.|
There was some hubbub a few months ago when it was revealed the Executive Director of the UK’s Year of Code initiative can’t code [link]. Not that technical (domain) competency is a sufficient condition for management and leadership, but I’d certainly call it a necessary condition. (I’ll use the world ‘technical’ below to refer to any sort of specialized domain, not just programming.)
Apparently a number of people don’t agree with the idea that competency in a domain is a requirement to manage that domain.* I find this idea infuriating and it can only end poorly.
Perhaps you have a manager who knows little about programming or design or whatever your specialty is, and you consider this person to be the best boss of all time. Great! I’ll call this person Your Boss for convenience. Here’s the problem:
At some point, Your Boss needs to make some contentious decisions. Maybe over your work, maybe over something you’re not directly involved with (I bet Your Boss was hated by a lot of people, too!). Your Boss has literally no ability to help resolve a technical decision. “Wait!” I hear you say. “My Boss is enlightened enough to know that the people closer to the problem should be making the decision!”
But who are those people closer to the problem? Who put them there? Oh, that’s right: Your Boss. But your boss has little technical knowledge. How is Your Boss supposed to decide who makes the more technical decisions? Without basic technical ability, Your Boss doesn’t even know what questions to ask. Your Boss can’t even learn; she doesn’t have the technical prerequisites. Instead of being able to provide leadership, Your Boss is left scratching her head. This is not leadership, and this is not management. This is a cancer and an organization that is unable to grow and learn.
It’s no surprise this topic is divisive. When Your Boss places a lot of trust in you, you are autonomous and think of Your Boss as the best boss of all time. But when someone runs up against you and Your Boss, they have no real recourse, because Your Boss trusts you and has no ability to further inspect the situation.
Certainly, superior ability or experience is not a requirement for management over a domain. But I thoroughly believe that not just familiarity, but some actual professional practice, with a domain is a requirement. I hope that if you are someone who believes in the myth of the competent non-technical manager, you’ll rethink your experience and view Your Boss in a more complete light.
* Clearly, at some point, you cannot be experienced in all the domains you manage, and need to trust people. Unfortunately we do this far to soon, and accept a development manager who has not developed, or an engineering manager who has not done much programming. In the case of the Year of Code Director, I think the issue is a non-technical background (in programming nor teaching) and a general lack of experience. If she had proven a wunderkind in her given field (which is, btw, basically PR/marketing/communications), maybe she should be given the benefit of the doubt. There are many examples where talented administrators have moved into new areas and been quite successful. But her appointment, along with most of the rest of the board, is pretty clear cronyism (and when you throw out technical merit and domain experience, you’re left pretty much with cronyism).