Results 1 to 5 of 5

Thread: Lightwave/Modo Bridge comparison

  1. #1
    Registered User
    Join Date
    Aug 2016
    Location
    a place
    Posts
    1,757

    Lightwave/Modo Bridge comparison

    Hi,

    I am starting a thread on this topic as I want to promote some improvements to Lightwave functionality and thus LW bridge productivity via a direct comparison between the two apps workflows.

    Note : this is not a mines better than yours thread. I just want a better LW /LW bridge. Take it elsewhere if you want to do that

    I will add my notes as I progress.
    Last edited by gar26lw; 04-07-2019 at 08:21 AM.

  2. #2
    Registered User
    Join Date
    Aug 2016
    Location
    a place
    Posts
    1,757
    So the first thing that I notice is that I generally find the LW bridge to be faster at updates, as Modo version does not stipulate (as far as I can tell) the setting of Unreal to use full CPU and requires me to push changes. That's great, it seems more immediate and I much prefer the auto push so the two apps become one. (this is really what the LW hub should do - it could be a connection between multiple apps and a real selling point for LW but i digress)

    Second thing of note. Modo's instancing system translates very well, this is similar to layouts duplication but because it is basically modeller, with modellers tools to replicate, it is a lot easier to get results predictably and quickly. Layout NEEDS this type of functionality badly to allow things to be... laid out!

    My third thing of note straight off the bat (and the biggest); Layout really needs a snapping system. The ability to snap and orientate duplicated items together in predictable increments, to points, edges, angles of degrees, etc is a significant workflow enhancement. This really cannot be stressed enough.

    I much prefer Lightwave's ability to specify a sub-directory in the Unreal Content path, this makes it easier to split up content to environments, character etc. I would like to see this extended so that a more granular approach could be adopted, allowing for a customised, organised project structure to be developed. Mainly so that the lightwave content and content folders generating the unreal data can match the unreal contents sub directories and everything stays neat and tidy. When generating large amounts of content, a LW content director structure for the main character is handy, one for props, with sub-folders etc can be useful so things are not on top of themselves. This also organises Unreal content.

    Lights seem to work a lot better in lightwave, modo stuffed them up straight away. I think some sort of link that matched as many settings in layout to unreal would be fantastic, even to go so far as a simple unreal panel that provided easy to set scene settings that made lightwave approximate Unreals real-time version or vise versa with image world or textured backdrop, gradient backdrop etc.

    that's it for now, only just started Please chime in, constructively with your experiences of the two.
    Last edited by gar26lw; 04-07-2019 at 08:28 AM.

  3. #3
    I'm a big supporter of this approach for lightwave. The way I see it, if this is done right and extended to other programs like 3dsMax this is the way to make lightwave relevant again in lots of production environments. It needs to be as friction-less as possible to pull pieces of complicated content into lightwave, apply modeller changes and have it back in other programs without even touching the file system. If lightwave can feel like a seamless extension of other tools then we can finally have the best of both worlds the speed and power of lightwave and the compatibility with games, visual effects and arch vis pipelines.

    Modo Bridge and materials plugins had to go through a learning experience with the unreal community that lightwave need not repeat. Originally they released the plugins as binary only versions without realising the flexibility that the community require, building custom source versions of projects and the core engine are not uncommon and must be supported. Eventually Foundry came to the conclusion that it didn't do them any harm to open the source for the plugins to give developers the support they needed.

    This approach has many benefits:
    1. Less pressure on them to support every new version of unreal the day it's released because half the time they don't even have to change anything it'll just recompile automatically on the new version.
    2. If bug's exist developers can fix them them and may even submit them to you for inclusion in the next official release.
    3. Allows companies to customise the results in unreal to fit into there pipeline. Datasmith is still not great at this.

    If completely opening the source isn't an option due to licencing issues you could always create a thin wrapper layer over a precompiled dll or static lib and still get most of the benefit.

  4. #4
    Registered User
    Join Date
    Aug 2016
    Location
    a place
    Posts
    1,757
    absolutely excellent idea

  5. #5
    I love this! Thanks for sharing!
    Matthew
    https://www.mhamiltonvisuals.com

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •