Page 3 of 15 FirstFirst 1234513 ... LastLast
Results 31 to 45 of 221

Thread: Cycles for Lightwave ? Tip and trick ?

  1. #31
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    Quote Originally Posted by samurai_x View Post
    They just released cycles 4d. The licensing seems affordable.
    Yeah, picked it up, the deep integration with X-Particles will be useful (X-Particles can drive Cycles4D in manners not supported by other engines). BTW, there's currently a 15% discount for existing X-Particles 3 owners (not sure if time-limited).

    I'm pretty busy atm, but when I get a chance I want to do some testing how its performance compares to Octane, Thea, and VrayForC4D.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  2. #32
    Super Member samurai_x's Avatar
    Join Date
    Jul 2015
    Location
    lalaland
    Posts
    1,231
    Quote Originally Posted by jwiede View Post
    Yeah, picked it up, the deep integration with X-Particles will be useful (X-Particles can drive Cycles4D in manners not supported by other engines). BTW, there's currently a 15% discount for existing X-Particles 3 owners (not sure if time-limited).

    I'm pretty busy atm, but when I get a chance I want to do some testing how its performance compares to Octane, Thea, and VrayForC4D.
    Someone did a comparison https://www.blenderguru.com/articles...les-vs-giants/
    Vray still wins geneally imo.
    But the price for cycles4d is really affordable. I would be very interested to have this in lw.

  3. #33
    I use cycles from time to time in Blender but imo it is a bit too noisy, unless one raises values to the sky the noise remain considerable.
    The other issue is shader setup. Similar to assembly coding.
    Last edited by bazsa73; 11-19-2016 at 02:47 AM.

  4. #34
    Super Member samurai_x's Avatar
    Join Date
    Jul 2015
    Location
    lalaland
    Posts
    1,231
    Quote Originally Posted by bazsa73 View Post
    I use cycles from time to time in Blender but imo it is a bit too noisy, unless one raises values to the sky the noise remain considerable.
    The other issue is shader setup. Similar to assembly coding.
    Its unbiased, its not a smart renderer
    But with that kind of pricing its really cheap to build 10 render nodes with multiple gpu each.
    It will cost around $825.
    I hope 3dslider is serious about this port.

  5. #35
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    Quote Originally Posted by samurai_x View Post
    Someone did a comparison https://www.blenderguru.com/articles...les-vs-giants/
    Vray still wins geneally imo.
    But the price for cycles4d is really affordable. I would be very interested to have this in lw.
    Insydium's dev already knew C4D inside and out, particularly w.r.t. render interfacing, etc. because of their prior X-Particles work. Drawing any conclusions w.r.t. pricing or effort required to port Cycles to LW based on Insydium's port of Cycles to C4D probably isn't wise.
    Last edited by jwiede; 11-20-2016 at 07:42 AM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  6. #36
    Registered User
    Join Date
    Apr 2015
    Location
    France
    Posts
    150
    Yeah ! Come back !, Ok I will return here from time to time some advancement to news in my dev.

    Quote Originally Posted by samurai_x View Post
    ...I hope 3dslider is serious about this port.
    Don't worry samurai_x, I work hard on this, the study is about 40% for LWSDK and more testing to my work in C++. It advances little by little but surely
    I need to study in C more depth too and working with C++. By this way, state of development is I think it will be out in 2017 (unknow date) once I will code more seriously.


    For Cycles4D it is awesome !

  7. #37
    Registered User
    Join Date
    Apr 2015
    Location
    France
    Posts
    150
    Some report to progress in 85% of study for LWSDK in my free time, pettry nice and some fun

    I am starting to study to port in modo too, but first to cycles for lightwave in priority and then modo. I am thinking for nodes how to integrate as OSL and for interacting on 3D model to render with cycles.

    Hope that will be more interesting to come.

  8. #38
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    Some suggestions w.r.t. design:

    1. Figure out the translation table between "LW entities" and "Cycles entities", and then look at the relevant LWSDK APIs to see what data structure translations will be needed to get the LW entities' data into a entity and format acceptable to Cycles. This kind of entity relationship diagram (ERD) is a key requirement for all external renderer integrations for any 3D package. Understanding requirements, configuration and use of LWSDK external-renderer-integration APIs also should occur here, in order to understand what LW requires from your plugin and/or Cycles as well.

    2. Determine which Cycles entities are "render-required" versus "render-optional", meaning which are basic entities and configuration you must satisfy for Cycles to function at even a basic level, versus entities and configuration which represent additional features and functionality but which are not essential to basic function.

    3. As part of figuring out #1 & #2, you'll discover entities tend to fall into 3 categories:
      • "directly usable" -- entities' formats are similar enough that transfer is more copying than translation.
      • "directly translatable" -- where both entities' formats are understood and are highly-interchangeable.
      • "complex/unknown translation" -- where either entities' formats are not well known (but needed), or formats are not well-suited for interchange.
      This info should guide you where to spend time researching, with resolving all render-required "complex/unknown translation" entities as top priority, followed by making algorithmic choices w.r.t. render-required "directly translatable" entities next. Finally resolve any render-optional entities' translation you consider important to V1.

    4. At this point, you should be more or less set to tackle basic/render-required GUI/UX -- come up with a basic enumeration of all the parameters you'll need to express to the user in order to give Cycles everything it needs for basic operation. Then take a look at LWSDK GUI capabilities in Panels/Xpanels and figure out a rough idea for a LW-feasible GUI config which yields the needed parameters. NOTE: This is not implementation, this is simply figuring out a _prototype_ GUI w.r.t. what types of parameters are needed and how to gather them using LWSDK Panels/Xpanels GUI elements.

      Do not worry about "pretty/usable" too much yet, focus on just enough to get things up and running. As you move beyond a functioning "basic implementation" you'll almost certainly want redo the GUI design and implementation anyway, so try to stick with minimal needs (and facilitating basic testability) for this prototype GUI.

    5. Once you've figured out translation handling, understand the relevant LWSDK and Cycles APIs, and have a prototype GUI notion in mind, you should have enough info to put together a basic viable design for initial implementation of your external render integration code, how it needs to be structured (functional/module-level breakdown), what unit tests will be needed for each module/functional-aspect, and so forth. Do so, this will become your implementation blueprint going forward.

    Hope this helps, just intended as a suggestion of where to start w.r.t. your project (you may already be past all this, but if not, I thought perhaps this might help). There's an implicit dependency analysis step in the numbered items above, and you should continually maintain your own dependency analysis as you go -- otherwise there's a chance you'll be forced into serious back-tracking/re-implementation to address missing but required dependencies by LW and/or Cycles.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  9. #39
    Registered User
    Join Date
    Apr 2015
    Location
    France
    Posts
    150
    Great suggestions, thank you jwiede, it helps me so much.

    It is hot topic for dev, but more i study more i get alot information, Cycles entities are ready it need to adapt in LW to translate so there are alot code to add and modify. For Gui I have some idea how to create thanks from tutorials, the problem are how to interact at 3D stuff and then convert in rendering as real time and update on window. I prefer to integrate in LW rather than external because the answer is up and fast to get for users, no need to tweak in/out. One more thing, I appreciate If we can talk too for more technic as scheme from LWSDK, data structure, exchange between LW and Cycles, pseudo algorithm, command, 3D, which function is for render engine ?

    My todo list :
    - finish to study and experiment for LWSDK
    - create and prototype UI for dialog, window, button (Panel/Xpanel)
    - retrieve on 3D models from LW to translate for Cycles
    - prototype for nodes shaders and update in realtime
    - experimental : support OSL
    - support static and animation
    - volumetric shaders
    - all shading : diffuse, glossy, SSS, etc...
    - hypervoxel support in Cycles ?
    - hair/particles support ?
    - Baking in Cycles ?
    - ...

    As soon as there is concrete in my dev, I would keep you informed.

  10. #40
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    More info/advice:

    The key API sets you'll use about for enumerating the scene entities are LWItemInfo (lwrender.h), LWObjectInfo (lwrender.h), LWSceneObjects (lwmeshes.h) and LWMeshInfo (lwmeshes.h). These four API sets will give you a near-complete view of all scene entities, the lion's share of relationships present and effects applied, and so forth. As you dig into the objects themselves you'll need to use other API sets to extract properties and so forth, but these four allow you to capture the essential scene graph info and organization.

    Surfacing is a tricky situation. There's a reason most third-party external renderers (with the exception of Kray) use their own surfacing systems -- it can be difficult and onerous to try to replicate LW surfacing definitions in other renderers in an accurate-enough manner to be valuable. The effort the Kray guys have put into ensuring surface compatibility for Kray is enormous, and there are _still_ cases (nodally) where Kray cannot properly replicate LW because certain key info isn't available.

    Given Cycles already has surfacing capabilities well beyond those of LW (f.e. OSL), so even if you were able to 100%-accurately convert LW surface definitions into Cycles surfacing, you'd still have to provide Cycles-specific surfacing support for all the surfacing elements in Cycles which lack LW equivalents. Cycles also uses different procedurals than LW, so you'd either need to "bake" LW procedurals for use in Cycles, or allow users to somehow define surfaces using Cycles procedurals. At the end of the day, there's a reason Maxwell Render, Octane, etc. all chose to use their own custom surface definitions within LW (separate from and parallel to LW surfacing definitions).

    I strongly recommend you approach surfacing similar to how Maxwell Render and Octane have approached it, rather than the Kray approach of trying to "reuse"/convert LW surfacing definitions directly. Not only is Cycles surfacing broader in capabilities than what LW surfacing can describe, the broad array of third-party nodes and shaders commonly used in LW surfacing make it very difficult to even reliably extract all details of LW surface definitions you'll commonly encounter.

    Perhaps consider conversion of "basic" LW surface properties, but (at least initially) I strongly recommend you take a look (via demos) at how Maxwell Render and Octane use/configure their renderers' surfacing definitions within LW, and emulate that approach. It's worth noting that even the Kray guys ultimately realized that relying on converting LW surfacing was holding them back, and that they'd be better off using their own, parallel surfacing definitions tuned for their render engine (supposedly coming in Kray 3.x).

    If this kind of info/advice isn't useful for you, please let me know and I'll stop posting it. Stay motivated! When you start to feel overwhelmed, write it all down, break it into sections, and simply iterate through them. Thorough planning helps you keep moving and on course, even when you can't see the destination from your current position. Having long-term goals ("Cycles integration in LW") is good, but you should also maintain a shorter-term daily or weekly goal ("parse entire LW scene graph using APIs") to better motivate forward progress.
    Last edited by jwiede; 01-12-2017 at 03:35 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  11. #41
    Registered User
    Join Date
    Jan 2016
    Location
    Stockholm
    Posts
    1,449
    Cycles isn't that easy to use in another engine. It (obviously) is tightly integrated with Blender, and it is a mess to get a grip of its connection points. There is a project to make Cycles an independent renderer for Blender, so you might want to have a look at that one too. But it is also quite old, quite possibly dropped. Although I am guessing you already know, this is the place to begin looking: https://wiki.blender.org/index.php/D.../Render/Cycles

    I think Embree would be an easier task to do than Cycles to be honest. As for potential market? Depending on what the next version of LW brings, it could affect it. But I think there is one regardless. If for no other reason than it is Cycles.

  12. #42
    Registered User
    Join Date
    Apr 2015
    Location
    France
    Posts
    150
    @jwiede : Useful for your advice, yes I was thinking to first paragrah for 3D Models but I need some more info on how to do it in programming, I must study it so if there is example on how to retrieve and translate in Cycles?
    Other thing, surfacing is of course I cannot replicate as accurately, it will be base of Cycles to render all shading cause it has his own calculation of surfacing but for LW is an approximation in Cycles and do more it too.

    @MichealT : Yes someone has says to me for making Embree, i dont know much for it, it is more likely raytracing API, a light that extend more in own your renderer. I am new and not yet for making my own renderer but I learn it. creacon I think he works on it. There are alot renderer, it may be Appleseed, Luxrender, Mitsuba, etc... I choose to Cycles because it is short, effective, powerful, simple, quite full feature, ready for implementation and C++.

  13. #43
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    Quote Originally Posted by 3dslider View Post
    @jwiede : Useful for your advice, yes I was thinking to first paragrah for 3D Models but I need some more info on how to do it in programming, I must study it so if there is example on how to retrieve and translate in Cycles?
    Well, I highly doubt you'll find any examples for translating LW internal object data to Cycles, that would require someone else to have already done most of the work for what you're trying to do.

    As for the info to do what I described in the first paragraph, the LWSDK documentation for the four API sets I described include descriptions of how to use them. Look at "(LWSDK dir)/html/index.html" in a browser and then under "Globals" for the docs on each of the API sets I described. There's an "Example" section in the description of LWItemInfo API set which demonstrates how to enumerate/traverse the entire object list and display some parameters for each object. From there, it's "just" using the other API sets to extract relationship and connected resource information about the scene entities. You won't need _all_ the data and entities/info those API sets can provide, but as a starting effort gathering all of it into your own data structures is a reasonable "learning exercise".

    Knowing what you do and do not need for Cycles is an important design aspect, which is why I'm recommending you first figure out the ERDs and mappings before trying to write a bunch of code.
    Last edited by jwiede; 01-13-2017 at 01:26 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  14. #44
    Registered User
    Join Date
    Apr 2015
    Location
    France
    Posts
    150
    Yes there are some examples, I believe that I rethink more in algorithm on how to achieve it, I ask someone for help in my dev but he says cannot helps me due from copyright, ok I understand and I will have to find a solution otherwise.

    LWSDK with doc, I read it, look like "as is" are fairly lean to explanation but good to starting in programming C/C++ and it can bright alot of possibility at result, it must be to choose very well too.

  15. #45
    Registered User
    Join Date
    Apr 2015
    Location
    France
    Posts
    150
    Probably I will be busy to post some news here due alot of amout work in my dev, I am working very hard in the scheme algorithm to try on implementing some code, very difficult but not impossible I think

    Also starting to study all code from Cycles to integrate in plugin, there will be to have some modification to adapt for conversion 3d Models... By then I hope to get a result.

Page 3 of 15 FirstFirst 1234513 ... LastLast

Tags for this Thread

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
  •