August Developer Meeting

[TheDuckCow]

To be populated as we go

Topics:

• Near term release: v3.6.1
• Mid to longer term, road to v4.0
• Vivy / materials

[TheDuckCow]

Wrap up notes:

• Talking about docs, we should do better than "everything on the readme"
• Could use built in wiki, but limited styling/control over structure (and will be like that probs foevereve based on the product feedback).
  • Pro: user editable
• Use githubpages (using static html delivery); but then use https://gohugo.io/ to compiles markdown into html to publish to a site, to make it easier to edit. Little extra work, but could be automated
• Takeaway: we should do something; but let's do it after 3.6.1
  • Patrick to do the quick patch of the mobs, just to be accurate; likely should use the new mc wiki: https://minecraft.wiki/w/Mob
• What to do for near future? (And what dev timeline cutoffs per here)
  • 3.6.1: cut off for pr's is today, ie just the one remaining
  • 3.6.2: aim to be more of a cleanup of pre-existing bugs, looking at the alpha cutting/selecting alpha faces. Likely to due with: non-1:1 aspect ratios
    • Let's aim for a date, and see what we finish between now and then.
    • PR cutoff = Sept 8th, aim to release Sept 1th
  • 3.7: Vivy! Mostly due to be a large change that is notable for users, not that we have to push it out that much
    • PR cutoff = Sept. 22nd, aim to release 29th or Oct 6th
  • 4.0: Longer term, no sooner than say Nov;
• Vivy, what remains:
  • UI: lot's of areas which aren't directly exposed in the UI
    • Refinements (ie a general material could apply to specific groups of blocks, e.g. emissive, desaturated). Need a way to let people indicate this.
    • Fallbacks
    • How to modify the config files, this part gets a bit weird: see example, vivy materials json example. Internally represented. Modifying a config after the fact. We could represent this as a node system vs a panel, but could represent.
    • Hooking up to other areas of material generation
  • TO start with:
    • Ability to define one layout to replace all others
    • Ideally the ability to name specific material overrides, so that we can functionally merge with the "sync materials" operator.
    • Clearer tracks for how people get to and save/update/open their vivy template(s).
      • Could use a custom folder for templates.
  • To do later:
    • Nodal config layout; first version, advanced users would have to edit the json (we can at least reveal that in user prefs/advanced)
• What's important for 4.0/new biggest features?
  • Layering resource packs (nice follow on after vivy)
  • MC bridge: daunting, need to have at least the above there first (so min. 4.1 or later)
  • Helpful horse panel / the ability to search for anything
  • Separate asset updates from MCprep updates; ie a separate repo for content (establishing
    • Would need to package the script which search and extracts contents from .jar -> future proofs a given install of MCprep, so we don't have to ship textures.
    • For asset/rigs, that can go to a separate repo for downloading ad hoc post-install.
    • Let's look into how we could use a github repo as a sort of static api for the asset browser remote asset features, so that users could download rigs they want outside of those which are "prepackaged"; and would be orgnaized in the asset browser which is a way better experience anyways.
  • Asset browser, would follow the above point
• So, we'll revisit asset browser to see how the remote repo is shaking out, but yes we want to move in this direction:
  • Pre-generating blocks
  • Searpting downlaods for rigs
  • Allowing people to cotribute more rigs ad hoc (without bloating MCprep downloads)
  • Still likely want to have a concept of "default" included rigs, which would be a one-time download after the addon is installed.

[StandingPadAnimations]

• Vivy, what remains:

  • TO start with:

    • Ability to define one layout to replace all others
    • Ideally the ability to name specific material overrides, so that we can functionally merge with the "sync materials"

I have an idea for how we could approach this: throw out the current UI and build a new UI from scratch. Although this might sound daunting, we do have to do massive UI refactoring in Vivy anyway, so we may as well start here. That way, we don't have to worry about the underlying logic having to go through massive refactors.

My idea is when a user modifies a material on an OBJ, we could have a side panel in the node editor (that only appears on OBJs) that would allow for turning the material into a Vivy material. Of course, we'd then have to make the transition from the current scene to a separate blend file smooth, but it would make getting into Vivy relatively easy for users, and the frontend would handle the more complex config parts. This would require adding a new refinement that allows selecting specific blocks, but to be honest, that was planned anyway as well.