AWS Thinkbox Discussion Forums

Winter Roadmap

Whew, fall went by fast.

I’m off to Canada tomorrow and going to be doing some roadmap meetings. any wishlists?

here are our current plans. as always please keep this internal.

  1. Krakatoa SR PY/C++ and Krakatoa MAYA Release Candidate in Dec, released as soon as it’s ready
  2. Deadline 6 should be feature complete and well into beta by end of year. RC in Jan? Feb?
  3. Draft 1 is in Release Candidate 3 - hope to have that released before Christmas
  4. Xmesh for Maya is back in action. No ETA yet, but I want to get this out in winter.
  5. MagmaFLUX [codeword] - PYQT node-based UI design has started. this will go many places, first up would be Magmaflow Maya
  6. Cinelab - getting new engine in place to be foundation for looks, fx etc. ETA is past due, but now scheduled for Dec
  7. Genome and Ember are getting sporadic attention, but plan is to refocus and get working Ember/particle reflow.
  8. Deadline 6.1 is in design phases, 7.0 is getting roadmapped. Now is the time to hear about feature requests!!! :exclamation:
  9. We have some magic coming for xmesh/prt [and maybe other places?] which we hope will improve file sizes :ugeek:

As things fall of the list above, developer resources are free’d up. client requests range from the following which is NOT in any particular order…

a. More draft features. node-based UI for draft [see magmaflux]
b. particle system - in max, standalone, etc.
c. finish frost 2 - huge list here
c2. port frost to maya?
d. xmesh 1.5? we have a small wishlist…“transform” channel being one [chad]
e. Krakatoa 2.5ish - out of core, or 3.0ish physical cameras, physically based lighting ‘style’ support [whatever this may entail]
f. PRT2.0

as for Deadline 6.1 - the goal is some additional features but no core revisions. e.g. better cloud support tools are a candidate.

feedback is requested!!

cb

Something spooky ate my message, so here it is again…

PRT 2.0 would be high on my list. Ideally, I’d like it done in time for the SR release, but I’m sure that’s very unlikely. It’s just that we expect a lot of SR use cases to be I/O bound.

I/O for Ember would be high on the list. Field3D, OpenVDB, your own format, I don’t really care, just want something to do caching and interchange with.

  • Chad

Feature Requests
A) BatchDraft GUI/Deadline Synergy.
B) Intelligent job run-time prediction in Deadline.
C) Plugin sync/application deployment through deadline.
D) Cloud Asset sync.

Those are still my big 4.

a - we are/have started a node-based cross-platform ui toolkit. the goal is to have a draft ui in v2. ill look at batchdraft, but v2 would encompass batchdraft methinks. i’ll get an internal discussion going.

b - we’ll need to spec this out, but I think this will fit into our v7 roadmap plans [which will allow for this and much more]

c/d - some of that is being discussed for v6.x, but honestly it’s a bit out of scope to build something for each rendering application in the short-term - HOWEVER. lots of thought is going into this fwiw. i’m taking the stance right now that the small 1-3 person;s needs can use something like dropbox/skydrive and the large facilities have their own asset pipeline. it’s the people inbetween [like you] that need something more robust, but not something that requires an entire department to sustain. so…i think that’s where you come in collaboration-wise…
cb

I would argue that batchDraft and the node based toolkit do not overlap. I see a node base as a way to create a template. For quickly tweaking a template and more importantly re-using a template with almost no changes a node-based UI is extremely over-complicated. However if a node based UI can create a new template for use within a batch scenario then all the better.

Privacy | Site terms | Cookie preferences