Coder Social home page Coder Social logo

Blender 2.x exporter. about pbrt-v4 HOT 5 CLOSED

stig-atle avatar stig-atle commented on June 23, 2024
Blender 2.x exporter.

from pbrt-v4.

Comments (5)

mmp avatar mmp commented on June 23, 2024

Fantastic! I'd be happy to add that as a submodule to pbrt-v4.

One question first (and then a second issue to mention): my inclination would be to have the submodule be in a exporters/blender directory (next to the out-of-date cinema4d one), with the thought that "io_scene_pbrt" doesn't make clear which modeling system it's for if someone is browsing the directory hierarchy. Of course, on the other hand, that's not the proper name of your exporter, so that might be confusing as well. Another option would be to have exporters/blender with a short README and then io_scene_pbrt as a subdirectory under that. Do you have opinions about this?

Second, pbrt's CMakeLists.txt has some logic that looks at the current submodule versions and makes sure they are at the expected git commit and nags the user to update their submodules if they're behind. As development proceeds, that commit id can be updated when there's significant new functionality in your exporter. It's probably not worth updating it too often, just to not bug users who aren't using it, but if you could send a PR now and again when that should be bumped, that'd be great.

from pbrt-v4.

stig-atle avatar stig-atle commented on June 23, 2024

Thanks a lot for the feedback!
I like this option:
Another option would be to have exporters/blender with a short README and then io_scene_pbrt as a subdirectory under that.

As I mentioned I'm working on adding all v4 things. So I plan to push that to a new branch until it's done.
So if you add the current 'master' then you will have the current v3 supported version (and use the --upgrade feature for v4).
I will do the v4 support in a separate branch during development.
When the v4 support is done I'll merge that to 'master' and then make a branch for the old v3 version.
This means that on your end you do just have to add master and I'll handle the rest on my end.

Does that sound OK to you?
I will also keep in mind what you said about the notifications about submodule versions.
If I tag them - will it only complain if a newer tagged version is added? or does it complain as soon as a new commit is done after the 'latest' tag?
If it only complains when there's a newer tag - then I'll make sure to not create many version tags, and only do that when it's ready for a release.

If it complains between each commit, then I'll just make sure to do any development in between in a separate branch, and then merge into master when needed to keep the notifications down.

from pbrt-v4.

mmp avatar mmp commented on June 23, 2024

Sounds good on the directory organization part.

As far as versions, commits, etc, you basically don't need to worry about it. My understanding of git submodules is that when I add one to pbrt, that basically records a place in the directory structure for the submodule, a URL to get it from, and a git commit hash to check out. Then everyone gets that exact same commit, no matter what you do in the original repository afterward.

Any time afterwards, on the pbrt side, I can update to a newer version of a particular submodule whenever it makes sense. (And then, the pbrt cmake script will nag users to run git submodule update, since they don't get the new version by default if they just ran git pull.) So, just let me know where I should grab the initial version, and let me know now and again when I should update on the pbrt side so that people get a newer version.

That all said, if it's not a submodule but is just linked to from the pbrt documentation, website, etc., then obviously people can more easily get the latest version but cloning the exporter themselves and then pulling whenever they want to update. I'm fine with whichever you prefer.

from pbrt-v4.

stig-atle avatar stig-atle commented on June 23, 2024

Thanks again.

I think we can start with a blender folder and a readme, which then points to the repo (and other places you want to make users know about the exporter). When I'm done with all pbrt-v4 features and it is stable it might make more sense to have it as a submodule then, because updates after that will be minimal. I just want users to easily find it if they use blender and want to use pbrt.

from pbrt-v4.

joeyskeys avatar joeyskeys commented on June 23, 2024

Hey guys, I happen to be working on the same task, checkout my repo if you are interested.

from pbrt-v4.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.