Appleseed · brlcad · Zulip Chat Archive

I was going to send you a link to my blog post but I'm suspended for some reason :(

Rahil Malik (Jan 07 2018 at 20:14):

i dont remeber how but i binded the EDF to camera and i want to knwo if i can share the .appleseed file here in public

Sean (Jan 07 2018 at 20:15):

Rahil Malik (Jan 07 2018 at 20:16):

Sean (Jan 07 2018 at 20:17):

Rahil Malik (Jan 07 2018 at 20:18):

Rahil Malik (Jan 07 2018 at 20:19):

and i imported a sphere , i converted a .g file to .obj and imported it in appleseed , the made an instance of it . and Now i can successfully see my sphere

Rahil Malik (Jan 07 2018 at 20:21):

Sean (Jan 07 2018 at 20:31):

Sean (Jan 07 2018 at 20:32):

Rahil Malik (Jan 07 2018 at 20:34):

Rahil Malik (Jan 07 2018 at 20:35):

Mahdi (Jan 07 2018 at 20:36):

Sean (Jan 07 2018 at 20:39):

Sean (Jan 07 2018 at 20:40):

Mahdi (Jan 07 2018 at 20:44):

I really wanted an afternoon to hack on that but I still can't get the sources working on my windows machine. Running linux on a vm and installing all the sources there would probably be my next move.

Sean (Jan 07 2018 at 20:45):

there's not enough time now, but if someone had spent the entire GCI just working on appleseed integration tasks, they probably would have won :)

Sean (Jan 07 2018 at 20:45):

as it is, I think everyone got stuck on the last task -- which was hard, but couldn't figure out a way to break it up better

caleb parks (Jan 07 2018 at 20:50):

I had a hard time doing the first appleseed task because the mac version is not working in anything after version 1.8

Mahdi (Jan 07 2018 at 20:51):

Are there any tasks that could be done in a couple days and would be considered highly rewarding?

Rahil Malik (Jan 08 2018 at 00:56):

Mahdi (Jan 08 2018 at 01:33):

Rahil Malik (Jan 08 2018 at 02:29):

Rahil Malik (Jan 08 2018 at 02:30):

Sean (Jan 08 2018 at 03:18):

Rahil Malik (Jan 08 2018 at 03:22):

Sean (Jan 08 2018 at 03:23):

Rahil Malik (Jan 08 2018 at 03:23):

Sean (Jan 08 2018 at 03:24):

Rahil Malik (Jan 08 2018 at 03:24):

Sean (Jan 08 2018 at 03:24):

Rahil Malik (Jan 08 2018 at 03:25):

Sean (Jan 08 2018 at 03:25):

Rahil Malik (Jan 08 2018 at 03:25):

Sean (Jan 08 2018 at 03:26):

Rahil Malik (Jan 08 2018 at 03:26):

Sean (Jan 08 2018 at 03:26):

Rahil Malik (Jan 08 2018 at 03:27):

Sean (Jan 08 2018 at 03:27):

Rahil Malik (Jan 08 2018 at 03:28):

Rahil Malik (Jan 08 2018 at 03:29):

Rahil Malik (Jan 08 2018 at 03:30):

Sean (Jan 08 2018 at 03:32):

it should simply look like a rendered sph. that's pink to tell you that something isn't set up right

Sean (Jan 08 2018 at 03:32):

Sean (Jan 08 2018 at 03:33):

Rahil Malik (Jan 08 2018 at 03:33):

Sean (Jan 08 2018 at 03:33):

Sean (Jan 08 2018 at 03:34):

it's pink because you've not told it what it should look like, what material it is

Sean (Jan 08 2018 at 03:34):

Rahil Malik (Jan 08 2018 at 03:34):

i actually created another prject and as soon as i import the object , the object instance is made and its there on th screen when i rendeer it

Rahil Malik (Jan 08 2018 at 03:34):

Sean (Jan 08 2018 at 03:35):

Rahil Malik (Jan 08 2018 at 03:36):

Sean (Jan 08 2018 at 03:36):

Rahil Malik (Jan 08 2018 at 03:37):

Rahil Malik (Jan 08 2018 at 03:38):

Sean (Jan 19 2018 at 05:17):

@Mitesh I see that franz explained the same to you about plugins a couple days ago

Mitesh (Jan 19 2018 at 07:56):

Jeff Sieu (Jan 19 2018 at 08:02):

Jeff Sieu (Jan 19 2018 at 08:04):

pluginerror.txt
This does not work without crashing Appleseed upon Rendering though.
The above error is returned (for me at least).

Mitesh (Jan 19 2018 at 08:06):

Jeff Sieu (Jan 19 2018 at 08:13):

Mitesh (Jan 19 2018 at 08:14):

Sean (Jan 19 2018 at 17:59):

aha @Jeff Sieu ... at a quick glance at that error log, I'd say you don't have resources initialized

Sean (Jan 19 2018 at 18:08):

Sean (Jan 19 2018 at 18:09):

then making sure each rt_shootray() not only passes one, but is passed the right one for a given thread

Sean (Jan 19 2018 at 18:10):

you'l have to figure out a way to determine which thread you are when the plugin is running

Mitesh (Jan 20 2018 at 01:38):

I couldn't use that plugin since i have windows...
But as @Sean suggested i removed all the code and tried adding printf(""); the build was sucessfull and also appleseed ran successfully....later on I again tried writing out file in which the hello world text is displayed(as I did in appleseed #3). and file was successfully loaded out.

Mitesh (Jan 20 2018 at 01:40):

@Jeff Sieu i saw you have included tcl libraries which i haven't maybe that's what causing the problem....

Jeff Sieu (Jan 20 2018 at 02:43):

@Sean i think I did that though, I initialised 100 resources and used bu_parallel_id to find out which cpu was being used

Jeff Sieu (Jan 20 2018 at 02:43):

Jeff Sieu (Jan 20 2018 at 02:49):

Jeff Sieu (Jan 20 2018 at 03:07):

/* in prep_brlcad \/ */
char title [1024] = {0};
rtip = rt_dirbuild(db_path.c_str(), title, sizeof(title));
m_resources = static_cast<resource*>(bu_calloc(1, sizeof(resource)*100, "appleseed"));
for (size_t i = 0; i < 100; i++) {
    rt_init_resource(&m_resources[i], i, rtip);
    RT_CK_RESOURCE(&m_resources[i]);
}

/* in intersect \/ */
int cpu = bu_parallel_id();
ap->a_resource = &m_resources[cpu];
rt_shootray(ap);

Jeff Sieu (Jan 20 2018 at 03:27):

For me, just printing out bu_parallel_id() during intersect() always gives me 0

Mitesh (Jan 20 2018 at 16:39):

extremely sorry...I have chemistry practicals final exam on monday...so I won't be much active..

Naseef (Jan 20 2018 at 19:33):

Sean (Jan 23 2018 at 00:28):

@Jeff Sieu bu_parallel_id() is only useful if you use bu_parallel() threading. appleseed is going to be doing their own threading, so you need to figure out which thread is running, or set/look up an ID, or hash an ID based on some system lookup, etc.

Sean (Jan 23 2018 at 00:29):

that 0 every time is the problem -- they're all using the same resource and clobbering data (hence the crash)

Mitesh (Jan 23 2018 at 09:01):

Sean (Jan 23 2018 at 09:02):

Mitesh (Jan 23 2018 at 09:05):

Mitesh (Jan 23 2018 at 09:06):

Sean (Jan 23 2018 at 09:06):

that doesn't look normal to me... there should just be one target_link_libraries directive

Sean (Jan 23 2018 at 09:06):

Mitesh (Jan 23 2018 at 09:07):

Sean (Jan 23 2018 at 09:08):

Sean (Jan 23 2018 at 09:12):

Sean (Jan 23 2018 at 09:13):

Mitesh (Jan 23 2018 at 09:13):

target_link_libraries (sphereobject
    ${APPLESEED_LIBRARIES} H:\\BRLCAD7.26.0\\lib\\libbu.lib H:\\BRLCAD7.26.0\\lib\\librt.lib H:\\BRLCAD7.26.0\\lib\\libbn.lib H:\\BRLCAD7.26.0\\lib\\libwdb.lib H:\\BRLCAD7.26.0\\lib\\librt-static.lib H:\\BRLCAD7.26.0\\lib\\tcl.lib H:\\BRLCAD7.26.0\\lib\\brlcad.lib
)

Sean (Jan 23 2018 at 09:13):

Mitesh (Jan 23 2018 at 09:14):

Sean (Jan 23 2018 at 09:14):

Sean (Jan 23 2018 at 09:15):

Sean (Jan 23 2018 at 09:16):

Mitesh (Jan 23 2018 at 09:20):

Sean (Jan 23 2018 at 09:21):

Mitesh (Jan 23 2018 at 09:21):

target_link_libraries (sphereobject
    ${APPLESEED_LIBRARIES} H:\\BRLCAD7.26.0\\lib\\brlcad.lib H:\\BRLCAD7.26.0\\lib\\libwdb.lib H:\\BRLCAD7.26.0\\lib\\librt.lib H:\\BRLCAD7.26.0\\lib\\libbn.lib H:\\BRLCAD7.26.0\\lib\\libbu.lib H:\\BRLCAD7.26.0\\lib\\tcl.lib  H:\\BRLCAD7.26.0\\lib\\openNURBS.lib
)

Mitesh (Jan 23 2018 at 09:23):

Sean (Jan 23 2018 at 09:23):

Sean (Jan 23 2018 at 09:24):

Mitesh (Jan 23 2018 at 09:24):

Sean (Jan 23 2018 at 09:24):

Sean (Jan 23 2018 at 09:25):

you say sphereobject, am I to assume this is appleseed's demo code? is it modified?

Sean (Jan 23 2018 at 09:25):

Mitesh (Jan 23 2018 at 09:27):

yes it is the appleseed's demo code. No it is not modified...it is being compiled in x64 release mode.

Sean (Jan 23 2018 at 09:28):

Mitesh (Jan 23 2018 at 09:29):

well i have simply copied the brlcad rtexample.c functions in it and for those functions I need libraries...

Sean (Jan 23 2018 at 09:48):

so ... when you tell me "No it is not modified", I start to doubt other responses :)

Sean (Jan 23 2018 at 09:48):

Sean (Jan 23 2018 at 09:49):

Mitesh (Jan 23 2018 at 10:00):

Sean (Jan 23 2018 at 10:02):

Mitesh (Jan 23 2018 at 10:02):

Sean (Jan 23 2018 at 10:03):

Mitesh (Jan 23 2018 at 10:04):

Sean (Jan 23 2018 at 10:04):

Sean (Jan 23 2018 at 10:05):

Mitesh (Jan 23 2018 at 10:09):

//
// This source file is part of appleseed.
// Visit http://appleseedhq.net/ for additional information and resources.
//
// This software is released under the MIT license.
//
// Copyright (c) 2017 Francois Beaune, The appleseedhq Organization
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to deal
// in the Software without restriction, including without limitation the rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
// THE SOFTWARE.
//

// appleseed.renderer headers.
#include "renderer/api/object.h"
#include "renderer/api/project.h"
#include "renderer/api/rendering.h"
#include "renderer/api/scene.h"
#include "renderer/api/types.h"

// todo: fix.
#include "renderer/kernel/shading/shadingray.h"

// appleseed.foundation headers.
#include "foundation/math/ray.h"
#include "foundation/math/scalar.h"
#include "foundation/math/vector.h"
#include "foundation/utility/api/specializedapiarrays.h"
#include "foundation/utility/containers/dictionary.h"
#include "foundation/utility/job/iabortswitch.h"
#include "foundation/utility/searchpaths.h"
#include "foundation/utility/string.h"
// appleseed.main headers.
#include "main/dllvisibility.h"
// Standard headers.
#include <algorithm>
#include <cmath>


namespace asf = foundation;
namespace asr = renderer;

namespace
{
    //
    // A sphere object.
    //
    // The sphere is assumed to be centered at the origin.
    //

    const char* Model = "sphere_object";

    class SphereObject
      : public asr::ProceduralObject
    {
      public:
        // Constructor.
        SphereObject(
            const char*                 name,
            const asr::ParamArray&      params)
          : asr::ProceduralObject(name, params)
          , m_lazy_region_kit(&m_region_kit)
        {
        }

        // Delete this instance.
        void release() override
        {
            delete this;
        }

        // Return a string identifying this object model.
        const char* get_model() const override
        {
            return Model;
        }

        // This method is called once before rendering each frame.
        // Returns true on success, false otherwise.
        virtual bool on_frame_begin(
            const asr::Project&         project,
            const asr::BaseGroup*       parent,
            asr::OnFrameBeginRecorder&  recorder,
            asf::IAbortSwitch*          abort_switch) override
        {
            if (!asr::ProceduralObject::on_frame_begin(project, parent, recorder, abort_switch))
                return false;

            m_radius = get_uncached_radius();
            m_rcp_radius = 1.0 / m_radius;

            return true;
        }

        // Compute the local space bounding box of the object over the shutter interval.
        asr::GAABB3 compute_local_bbox() const override
        {
            const auto r = static_cast<asr::GScalar>(get_uncached_radius());
            return asr::GAABB3(asr::GVector3(-r), asr::GVector3(r));
        }

        // Return the region kit of the object.
        asf::Lazy<asr::RegionKit>& get_region_kit() override
        {
            return m_lazy_region_kit;
        }

        // Access materials slots.
        size_t get_material_slot_count() const override
        {
            return 1;
        }
        const char* get_material_slot(const size_t index) const override
        {
            return "default";
        }

        // Compute the intersection between a ray expressed in object space and
        // the surface of this object and return detailed intersection results.
        void intersect(
            const asr::ShadingRay&  ray,
            IntersectionResult&     result) const override
        {
            const double Epsilon = 1.0e-6;

            const double a = asf::dot(ray.m_org, ray.m_dir);
            const double b = asf::square(a) - dot(ray.m_org, ray.m_org) + asf::square(m_radius);

            if (b < 0.0)
            {
                result.m_hit = false;
                return;
            }

            const double c = std::sqrt(b);

            double t = -a - c;
            if (t < std::max(ray.m_tmin, Epsilon) || t >= ray.m_tmax)
            {
                t = -a + c;
                if (t < std::max(ray.m_tmin, Epsilon) || t >= ray.m_tmax)
                {
                    result.m_hit = false;
                    return;
                }
            }

            result.m_hit = true;

            result.m_distance = true;
            const asf::Vector3d n = asf::normalize(ray.point_at(t));
            result.m_geometric_normal = n;
            result.m_shading_normal = n;

            const asf::Vector3f p(ray.point_at(t) * m_rcp_radius);
            result.m_uv[0] = std::acos(p.y) * asf::RcpPi<float>();
            result.m_uv[1] = std::atan2(-p.z, p.x) * asf::RcpTwoPi<float>();

            result.m_material_slot = 0;

        }

        // Compute the intersection between a ray expressed in object space and
        // the surface of this object and simply return whether there was a hit.
        bool intersect(
            const asr::ShadingRay&  ray) const override
        {

            const double Epsilon = 1.0e-6;

            const double a = asf::dot(ray.m_org, ray.m_dir);
            const double b = asf::square(a) - dot(ray.m_org, ray.m_org) + asf::square(m_radius);

            if (b < 0.0)
                return false;

            const double c = std::sqrt(b);

            const double t1 = -a - c;
            if (t1 >= std::max(ray.m_tmin, Epsilon) && t1 < ray.m_tmax)
                return true;

            const double t2 = -a + c;
            if (t2 >= std::max(ray.m_tmin, Epsilon) && t2 < ray.m_tmax)
                return true;

            return false;


        }


      private:
        asr::RegionKit              m_region_kit;
        asf::Lazy<asr::RegionKit>   m_lazy_region_kit;
        double                      m_radius;
        double                      m_rcp_radius;

        double get_uncached_radius() const
        {
            return m_params.get_optional<double>("radius");
        }
    };


    //
    // Factory for the new object model.
    //

    class SphereObjectFactory
      : public asr::IObjectFactory
    {
      public:
        // Delete this instance.
        void release() override
        {
            delete this;
        }

        // Return a string identifying this object model.
        const char* get_model() const override
        {
            return Model;
        }

        // Return metadata for this object model.
        asf::Dictionary get_model_metadata() const override
        {
            return
                asf::Dictionary()
                    .insert("name", Model)
                    .insert("label", "Sphere Object");

        }

        // Return metadata for the inputs of this object model.
        asf::DictionaryArray get_input_metadata() const override
        {
            asf::DictionaryArray metadata;

            metadata.push_back(
                asf::Dictionary()
                    .insert("name", "radius")
                    .insert("label", "Radius")
                    .insert("type", "numeric")
                    .insert("min",
                        asf::Dictionary()
                            .insert("value", "0.0")
                            .insert("type", "hard"))
                    .insert("max",
                        asf::Dictionary()
                            .insert("value", "10.0")
                            .insert("type", "soft"))
                    .insert("use", "optional")
                    .insert("default", "1.0"));

            return metadata;
        }

        // Create a new single empty object.
        asf::auto_release_ptr<asr::Object> create(
            const char*                 name,
            const asr::ParamArray&      params) const override
        {
            return asf::auto_release_ptr<asr::Object>(new SphereObject(name, params));
        }

        // Create objects, potentially from external assets.
        bool create(
            const char*                 name,
            const asr::ParamArray&      params,
            const asf::SearchPaths&     search_paths,
            const bool                  omit_loading_assets,
            asr::ObjectArray&           objects) const override
        {
            objects.push_back(create(name, params).release());
            return true;
        }
    };
}


//
// Plugin entry point.
//

extern "C"
{
    APPLESEED_DLL_EXPORT asr::IObjectFactory* appleseed_create_object_factory()
    {
        return new SphereObjectFactory();
    }
}

Sean (Jan 23 2018 at 10:19):

Mitesh (Jan 23 2018 at 10:20):

Sean (Jan 23 2018 at 10:24):

Sean (Jan 23 2018 at 10:25):

like just include a bu header, then make one bu function call like printing bu_parallel_id() or printing a bu_vls string via bu_vls_addr().

Sean (Jan 23 2018 at 10:25):

Jeff Sieu (Jan 23 2018 at 10:26):

Sean (Jan 23 2018 at 10:26):

Sean (Jan 23 2018 at 10:27):

Sean (Jan 23 2018 at 10:28):

Mitesh (Jan 23 2018 at 10:33):

//
// This source file is part of appleseed.
// Visit http://appleseedhq.net/ for additional information and resources.
//
// This software is released under the MIT license.
//
// Copyright (c) 2017 Francois Beaune, The appleseedhq Organization
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to deal
// in the Software without restriction, including without limitation the rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
// THE SOFTWARE.
//

// appleseed.renderer headers.
#include "renderer/api/object.h"
#include "renderer/api/project.h"
#include "renderer/api/rendering.h"
#include "renderer/api/scene.h"
#include "renderer/api/types.h"

// todo: fix.
#include "renderer/kernel/shading/shadingray.h"

// appleseed.foundation headers.
#include "foundation/math/ray.h"
#include "foundation/math/scalar.h"
#include "foundation/math/vector.h"
#include "foundation/utility/api/specializedapiarrays.h"
#include "foundation/utility/containers/dictionary.h"
#include "foundation/utility/job/iabortswitch.h"
#include "foundation/utility/searchpaths.h"
#include "foundation/utility/string.h"

// appleseed.main headers.
#include "main/dllvisibility.h"
// Standard headers.
#include <algorithm>
#include <cmath>


#include "H:\BRLCAD7.26.0\include\brlcad\common.h"
#include <stdlib.h>
#include <math.h>
#include <string.h>
#include <stdio.h>
#include "windows.h"
#include "H:\BRLCAD7.26.0\include\brlcad\vmath.h"       /* vector math macros */
#include "H:\BRLCAD7.26.0\include\brlcad\raytrace.h"        /* librt interface definitions */
#include <iostream>
#include <fstream>
#include "renderer/api/object.h"
#include "renderer/api/project.h"
#include "renderer/api/rendering.h"
#include "renderer/api/scene.h"
#include "renderer/api/types.h"

#define BU_DLL_IMPORTS

namespace asf = foundation;
namespace asr = renderer;


int
hit(struct application *ap, struct partition *PartHeadp, struct seg *UNUSED(segs))
{
    /* iterating over partitions, this will keep track of the current
    * partition we're working on.
    */


    struct partition *pp;

    /* will serve as a pointer for the entry and exit hitpoints */
    struct hit *hitp;

    /* will serve as a pointer to the solid primitive we hit */
    struct soltab *stp;

    /* will contain surface curvature information at the entry */
    struct curvature cur = RT_CURVATURE_INIT_ZERO;

    /* will contain our hit point coordinate */
    point_t pt;

    /* will contain normal vector where ray enters geometry */
    vect_t inormal;

    /* will contain normal vector where ray exits geometry */
    vect_t onormal;

    /* iterate over each partition until we get back to the head.
    * each partition corresponds to a specific homogeneous region of
    * material.
    */
    for (pp = PartHeadp->pt_forw; pp != PartHeadp; pp = pp->pt_forw) {

        /* print the name of the region we hit as well as the name of
        * the primitives encountered on entry and exit.
        */
        bu_log("\n--- Hit region %s (in %s, out %s)\n",
            pp->pt_regionp->reg_name,
            pp->pt_inseg->seg_stp->st_name,
            pp->pt_outseg->seg_stp->st_name);

        /* entry hit point, so we type less */
        hitp = pp->pt_inhit;

        /* construct the actual (entry) hit-point from the ray and the
        * distance to the intersection point (i.e., the 't' value).
        */
        VJOIN1(pt, ap->a_ray.r_pt, hitp->hit_dist, ap->a_ray.r_dir);

        /* primitive we encountered on entry */
        stp = pp->pt_inseg->seg_stp;

        /* compute the normal vector at the entry point, flipping the
        * normal if necessary.
        */
        RT_HIT_NORMAL(inormal, hitp, stp, &(ap->a_ray), pp->pt_inflip);

        /* print the entry hit point info */
        rt_pr_hit("  In", hitp);
        /*
        VPRINT("  Ipoint", pt);
        VPRINT("  Inormal", inormal);

        */

        /* This next macro fills in the curvature information which
        * consists on a principle direction vector, and the inverse
        * radii of curvature along that direction and perpendicular
        * to it.  Positive curvature bends toward the outward
        * pointing normal.
        */
        RT_CURVATURE(&cur, hitp, pp->pt_inflip, stp);

        /* print the entry curvature information */
        /*VPRINT("PDir", cur.crv_pdir);*/
        bu_log(" c1=%g\n", cur.crv_c1);
        bu_log(" c2=%g\n", cur.crv_c2);

        /* exit point, so we type less */
        hitp = pp->pt_outhit;

        /* construct the actual (exit) hit-point from the ray and the
        * distance to the intersection point (i.e., the 't' value).
        */
        VJOIN1(pt, ap->a_ray.r_pt, hitp->hit_dist, ap->a_ray.r_dir);

        /* primitive we exited from */
        stp = pp->pt_outseg->seg_stp;

        /* compute the normal vector at the exit point, flipping the
        * normal if necessary.
        */
        RT_HIT_NORMAL(onormal, hitp, stp, &(ap->a_ray), pp->pt_outflip);

        /* print the exit hit point info */
        rt_pr_hit("  Out", hitp);
        /*VPRINT("  Opoint", pt);
        VPRINT("  Onormal", onormal);*/

    }

    /* A more complicated application would probably fill in a new
    * local application structure and describe, for example, a
    * reflected or refracted ray, and then call rt_shootray() for
    * those rays.
    */

    /* Hit routine callbacks generally return 1 on hit or 0 on miss.
    * This value is returned by rt_shootray().
    */
    return 1;
}



int
miss(struct application *UNUSED(ap))
{
    bu_log("missed\n");

    return 0;

}


namespace
{
    //
    // A sphere object.
    //
    // The sphere is assumed to be centered at the origin.
    //

    const char* Model = "sphere_object";

    class SphereObject
      : public asr::ProceduralObject
    {
      public:
        // Constructor.
        SphereObject(
            const char*                 name,
            const asr::ParamArray&      params)
          : asr::ProceduralObject(name, params)
          , m_lazy_region_kit(&m_region_kit)
        {
        }

        // Delete this instance.
        void release() override
        {
            delete this;
        }

        // Return a string identifying this object model.
        const char* get_model() const override
        {
            return Model;
        }

        // This method is called once before rendering each frame.
        // Returns true on success, false otherwise.
        virtual bool on_frame_begin(
            const asr::Project&         project,
            const asr::BaseGroup*       parent,
            asr::OnFrameBeginRecorder&  recorder,
            asf::IAbortSwitch*          abort_switch) override
        {
            if (!asr::ProceduralObject::on_frame_begin(project, parent, recorder, abort_switch))
                return false;

            m_radius = get_uncached_radius();
            m_rcp_radius = 1.0 / m_radius;

            return true;
        }

        // Compute the local space bounding box of the object over the shutter interval.
        asr::GAABB3 compute_local_bbox() const override
        {
            const auto r = static_cast<asr::GScalar>(get_uncached_radius());
            return asr::GAABB3(asr::GVector3(-r), asr::GVector3(r));
        }

        // Return the region kit of the object.
        asf::Lazy<asr::RegionKit>& get_region_kit() override
        {
            return m_lazy_region_kit;
        }

        // Access materials slots.
        size_t get_material_slot_count() const override
        {
            return 1;
        }
        const char* get_material_slot(const size_t index) const override
        {
            return "default";
        }

        // Compute the intersection between a ray expressed in object space and
        // the surface of this object and return detailed intersection results.
        void intersect(
            const asr::ShadingRay&  ray,
            IntersectionResult&     result) const override
        {
            const double Epsilon = 1.0e-6;

            const double a = asf::dot(ray.m_org, ray.m_dir);
            const double b = asf::square(a) - dot(ray.m_org, ray.m_org) + asf::square(m_radius);

            if (b < 0.0)
            {
                result.m_hit = false;
                return;
            }

            const double c = std::sqrt(b);

            double t = -a - c;
            if (t < std::max(ray.m_tmin, Epsilon) || t >= ray.m_tmax)
            {
                t = -a + c;
                if (t < std::max(ray.m_tmin, Epsilon) || t >= ray.m_tmax)
                {
                    result.m_hit = false;
                    return;
                }
            }

            result.m_hit = true;

            result.m_distance = true;
            const asf::Vector3d n = asf::normalize(ray.point_at(t));
            result.m_geometric_normal = n;
            result.m_shading_normal = n;

            const asf::Vector3f p(ray.point_at(t) * m_rcp_radius);
            result.m_uv[0] = std::acos(p.y) * asf::RcpPi<float>();
            result.m_uv[1] = std::atan2(-p.z, p.x) * asf::RcpTwoPi<float>();

            result.m_material_slot = 0;

            struct application  ap;
            int argc = 3;
            static struct rt_i *rtip;


            char title[1024] = { 0 };


            if (argc < 3) {
                bu_exit(1, "Usage: %s model.g objects...\n", "sphereobject");
            }

            rtip = rt_dirbuild("sphere.g", title, sizeof(title));
            if (rtip == RTI_NULL) {
                bu_exit(2, "Building the database directory for [%s] FAILED\n", "sphere.g");
            }

        }

   ```

Mitesh (Jan 23 2018 at 10:35):

Actually I was check int main statement of rtexample.c line by line....
when I reached this rtip = rt_dirbuild("sphere.g", title, sizeof(title)); line I found that when I don't include it...it works i.e sphereobject renders and there are no issues

Mitesh (Jan 23 2018 at 10:36):

but when I include it ( rtip = rt_dirbuild("sphere.g", title, sizeof(title));) it shows error.

Mitesh (Jan 23 2018 at 10:39):

Mitesh (Jan 23 2018 at 10:44):

Jeff Sieu (Jan 23 2018 at 11:17):

Sean (Jan 23 2018 at 16:03):

@Jeff Sieu that's okay, there's still a couple slow ways that should work or you can look into exposing the current thread (better)

Sean (Jan 23 2018 at 16:12):

@Jeff Sieu try this poor man's way -- ask franz what he's using for threading, but assuming it's pthreads or boost threads or std::thread, then something like this should work

Jeff Sieu (Jan 23 2018 at 16:15):

I think it's pthreads, I dug up a bit in their code and found a few pthread_ts here and there.

Jeff Sieu (Jan 23 2018 at 16:16):

I tried calling pthread_self(); to get the current thread id, which actually works.

Sean (Jan 23 2018 at 16:17):

static in get_id() { static std::unordered_map<std::thread::id, int> ids; static int next; static std::mutex m; auto thread = std::this_thread::get_id(); auto id = ids[thread]; std::lock(m); id = ++next; ids[thread] = id; std::unlock(m); return id - 1; }

Sean (Jan 23 2018 at 16:18):

so in on_frame_begin() or wherever you run dirbuild, you'll need to rt_resource_init() a bunch of resources (say 1024)

Sean (Jan 23 2018 at 16:19):

then in intersect() where you are calling rt_shootray(), call get_id() (which needs to be compiled as c++ obviously)

Sean (Jan 23 2018 at 16:19):

that's got some c++11 in there, so you might need to add --std=c++11 compile flags

Sean (Jan 23 2018 at 16:20):

Jeff Sieu (Jan 23 2018 at 16:22):

Jeff Sieu (Jan 23 2018 at 16:23):

Sean (Jan 23 2018 at 16:23):

Sean (Jan 23 2018 at 16:24):

Jeff Sieu (Jan 23 2018 at 16:29):

hmm, is this supposed to return higher and higher numbers? it sorta increases to something like 40000 in 5 seconds

Sean (Jan 23 2018 at 16:55):

Sean (Jan 23 2018 at 16:56):

Jeff Sieu (Jan 23 2018 at 17:06):

int cpu = get_id();
ap->a_resource = &m_resources[cpu];
rt_shootray(ap);

ERROR: NULL struct seg pointer, file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1758

ERROR: NULL struct seg pointer, file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1758

Saving stack trace to appleseed.studio-18336-bomb.log
BU_ASSERT((void *)(((struct bu_list *)(_zap))->forw) != (void *)NULL), failed, file /home/jeff/Documents/brlcad/src/librt/shoot.c, line 1503

BU_ASSERT failure

BU_ASSERT failure

rt_boolfinal:  sorting defect 5.014334e+02 > 2.162338e-318! x0 y0 lvl0, diff = 501.433
sort defect is between parts 0x7f6410007d70 and (nil)

ERROR: NULL struct partition pointer, file /home/jeff/Documents/brlcad/src/librt/pr.c, line 112

ERROR: NULL struct partition pointer, file /home/jeff/Documents/brlcad/src/librt/pr.c, line 112


ERROR: bad pointer 0x7f644b097300: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

ERROR: bad pointer 0x7f644b097300: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

ERROR: bad pointer 0x7f6448892280: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

ERROR: bad pointer 0x7f6448892280: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

write failed: Bad file descriptor

ERROR: bad pointer 0x7f64437fb280: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

ERROR: bad pointer 0x7f64437fb280: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

ERROR: bad pointer 0x7f644a896300: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

ERROR: bad pointer 0x7f644a896300: s/b struct partition(x87687681), was pt_hd magic(x87687680), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 1490

write failed: Bad file descriptor

ERROR: bad pointer 0x7f646c56f118: s/b struct seg(x98bcdef1), was bu_list(x1016580), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 175


Bad magic number in re_solid_btiv list

Bad magic number in re_solid_btiv list

ERROR: bad pointer 0x7f646c56f118: s/b struct seg(x98bcdef1), was bu_list(x1016580), file /home/jeff/Documents/brlcad/src/librt/bool.c, line 175

[1]    18336 segmentation fault (core dumped)  ../../../bin/Release/appleseed.studio

Sean (Jan 24 2018 at 05:48):

@Mitesh so you went from 0 to 10 in that jump ... way too big a step since you're facing problems

Sean (Jan 24 2018 at 05:51):

there are a number of issues in the code, so I suggest you comment-out all the brl-cad code and start with something super simple like I mentioned the other day -- a single bu call

Sean (Jan 24 2018 at 06:00):

then it'll be easier to sort out the header includes and bu import, make sure that works before jumping to a far more complicated code setup with librt and other issues

Sean (Jan 24 2018 at 06:08):

@Jeff Sieu that's still looking like initialization failure/corruption. what's the rest of your code look like?

Sean (Jan 24 2018 at 06:09):

you need to set a bunch of other ap fields, like the a_rt_i to what you prepped, and the resources had to be initialized

Jeff Sieu (Jan 25 2018 at 14:54):

Jeff Sieu (Jan 27 2018 at 17:43):

Sean (Jan 30 2018 at 02:30):

@Jeff Sieu you have to be SUPER close... I'm not seeing any blatant mistakes in the code

Sean (Jan 30 2018 at 02:32):

except you did miss the follow-up corrections I mentioned, like initializing next to 0...

Sean (Jan 30 2018 at 02:32):

Sean (Jan 30 2018 at 02:33):

Mitesh (Jan 30 2018 at 03:20):

no....I have commented out the whole rtexample.c
then added bu_log("welcome");
It was built successfully.
but when I opened sphereobject.appleseed got same result

Sean (Jan 30 2018 at 03:21):

Mitesh (Jan 30 2018 at 03:22):

Sean (Jan 30 2018 at 03:22):

Mitesh (Jan 30 2018 at 03:23):

1>------ Build started: Project: sphereobject, Configuration: Release x64 ------
1> sphereobject.cpp
1> Unknown compiler version - please run the configure tests and report the results
1>h:\brlcad7.26.0\include\brlcad\brep/bbnode.h(277): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>h:\brlcad7.26.0\include\brlcad\brep/bbnode.h(278): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>h:\brlcad7.26.0\include\brlcad\brep/bbnode.h(279): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>h:\brlcad7.26.0\include\brlcad\brep/bbnode.h(280): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>h:\brlcad7.26.0\include\brlcad\brep/bbnode.h(281): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>h:\brlcad7.26.0\include\brlcad\brep/bbnode.h(282): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1> Creating library H:/task5/appleseed/samples/cpp/sphereobject/build/Release/sphereobject.lib and object H:/task5/appleseed/samples/cpp/sphereobject/build/Release/sphereobject.exp
1> sphereobject.vcxproj -> H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Sean (Jan 30 2018 at 03:30):

Mitesh (Jan 30 2018 at 03:30):

Sean (Jan 30 2018 at 03:30):

Sean (Jan 30 2018 at 03:31):

Mitesh (Jan 30 2018 at 03:31):

Sean (Jan 30 2018 at 03:32):

adding the bu_log() call will cause the linker to look for that symbol, which is in libbu.lib

Mitesh (Jan 30 2018 at 03:32):

Sean (Jan 30 2018 at 03:32):

so in order for it to find it, it needs 1) to be told where the lib is and 2) to import that function

Sean (Jan 30 2018 at 03:32):

Mitesh (Jan 30 2018 at 03:33):

Sean (Jan 30 2018 at 03:33):

Sean (Jan 30 2018 at 03:34):

you'd have to guarantee it's included before anything that potentially includes any bu header

Sean (Jan 30 2018 at 03:34):

Sean (Jan 30 2018 at 03:35):

you should also remove all libs except appleseed_libraries and libbu.lib from the target_link_libraries line

Mitesh (Jan 30 2018 at 03:40):

Sean (Jan 30 2018 at 03:42):

Mitesh (Jan 30 2018 at 03:42):

Mitesh (Jan 30 2018 at 03:43):

failed to load project file H:\task5\appleseed\samples\cpp\sphereobject\sphereobject.appleseed (1 error, 0 warning).

Mitesh (Jan 30 2018 at 03:43):

Sean (Jan 30 2018 at 03:44):

Mitesh (Jan 30 2018 at 03:45):

could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.

Sean (Jan 30 2018 at 03:45):

Sean (Jan 30 2018 at 03:46):

Mitesh (Jan 30 2018 at 03:46):

Sean (Jan 30 2018 at 03:47):

Mitesh (Jan 30 2018 at 03:47):

Sean (Jan 30 2018 at 03:48):

so is that just now or some time earlier? I have no idea what time it is for you :)

Mitesh (Jan 30 2018 at 03:48):

Sean (Jan 30 2018 at 03:49):

Mitesh (Jan 30 2018 at 03:50):

2018-01-30T03:43:13.163952Z <001> 2018-01-30T03:43:13.163952Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.164955Z <001> 2018-01-30T03:43:13.170823Z <001> 2018-01-30T03:43:13.205736Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.206740Z <002> 2018-01-30T03:43:13.226526Z <002> 2018-01-30T03:43:13.226526Z <002> 2018-01-30T03:43:13.226526Z <002> 2018-01-30T03:43:13.228600Z <002> 2018-01-30T03:43:13.230739Z <002> 2018-01-30T03:43:13.230739Z <002> 2018-01-30T03:43:13.232384Z <002> 2018-01-30T03:43:13.232384Z <002> 2018-01-30T03:43:13.232384Z <002> 2018-01-30T03:43:13.234699Z <002> 2018-01-30T03:43:13.235723Z <002> 2018-01-30T03:43:13.235723Z <002> 2018-01-30T03:43:13.236867Z <002> 2018-01-30T03:43:13.236867Z <002> 2018-01-30T03:43:13.237934Z <002> 2018-01-30T03:43:13.243131Z <002> 2018-01-30T03:43:13.244134Z <002> 2018-01-30T03:43:13.244134Z <002> 2018-01-30T03:43:13.245137Z <002> 2018-01-30T03:43:13.245137Z <002> 2018-01-30T03:43:13.246140Z <002> 2018-01-30T03:43:13.247296Z <002> 2018-01-30T03:43:13.249374Z <002> 2018-01-30T03:43:13.249374Z <002> 2018-01-30T03:43:13.251061Z <002> 2018-01-30T03:43:13.251061Z <002> 2018-01-30T03:43:13.251385Z <002> 2018-01-30T03:43:13.253891Z <002> 2018-01-30T03:43:13.255896Z <002> 2018-01-30T03:43:13.255896Z <002> 2018-01-30T03:43:13.257400Z <002> 2018-01-30T03:43:13.257400Z <002> 2018-01-30T03:43:13.258408Z <002> 2018-01-30T03:43:13.262413Z <002> 2018-01-30T03:43:13.263417Z <002> 38 MB info | appleseed.dll version 1.8.0-beta (SSE 4.2), Release configuration
38 MB info | compiled on Nov 26 2017 at 17:11:55 using Microsoft Visual C++ version 1900
38 MB info | system information:
38 MB info | architecture x86 64-bit
38 MB info | logical cores 4
38 MB info | L1 data cache size 32.0 KB, line size 64 bytes
38 MB info | L2 cache size 256.0 KB, line size 64 bytes
38 MB info | L3 cache size 3.0 MB, line size 64 bytes
38 MB info | instruction sets sse sse2 sse3 ssse3 sse4.1 sse4.2 avx avx2 fma3
38 MB info | physical memory size 7.8 GB
38 MB info | virtual memory size 9.1 GB
39 MB info | successfully loaded settings from H:\appleseed\settings\appleseed.studio.xml.
40 MB info | loading project file H:\task5\appleseed\samples\cpp\sphereobject\sphereobject.appleseed...
41 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of aov plugins...
41 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed aov plugin because it does not export a appleseed_create_aov_factory() function.
41 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.
41 MB debug | .
41 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
41 MB debug | .
41 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of assembly plugins...
45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed assembly plugin because it does not export a appleseed_create_assembly_factory() function.
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of bsdf plugins...
45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed bsdf plugin because it does not export a appleseed_create_bsdf_factory() function.
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of bssrdf plugins...
45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed bssrdf plugin because it does not export a appleseed_create_bssrdf_factory() function.
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of camera plugins...
45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed camera plugin because it does not export a appleseed_create_camera_factory() function.
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of edf plugins...
45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed edf plugin because it does not export a appleseed_create_edf_factory() function.
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of environment edf plugins...
45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed environment edf plugin because it does not export a appleseed_create_environment_edf_factory() function.
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
45 MB debug | .
45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of environment shader plugins...
46 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed environment shader plugin because it does not export a appleseed_create_environment_shader_factory() function.
46 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\libbu.dll: Cannot load shared library H:\task5\appleseed\samples

Sean (Jan 30 2018 at 03:54):

Sean (Jan 30 2018 at 03:56):

try changing "SHARED" to "MODULE" in your cmakelists.txt file, and remove that libbu.dll from sphereobject\build\Release

Sean (Jan 30 2018 at 03:57):

if it can't find the dll where you told cmake it was at, you have other problems -- you shouldn't need to copy the libs into there

Sean (Jan 30 2018 at 03:59):

another problem that may be causing this is your use of full paths instead of specifying libs properly via search paths -- that can cause different dynamic linker behavior when it tries to find dependency libraries

Sean (Jan 30 2018 at 03:59):

Mitesh (Jan 30 2018 at 03:59):

Sean (Jan 30 2018 at 03:59):

Sean (Jan 30 2018 at 04:00):

Mitesh (Jan 30 2018 at 04:01):

Sean (Jan 30 2018 at 04:02):

can you just paste the text like before -- it's hard to tell what's being left out

Sean (Jan 30 2018 at 04:03):

always important to read all your output when debugging, have a good idea what each message is saying ;)

Mitesh (Jan 30 2018 at 04:05):

2018-01-30T04:00:22.792441Z <001> 38 MB info | appleseed.dll version 1.8.0-beta (SSE 4.2), Release configuration
2018-01-30T04:00:22.792441Z <001> 38 MB info | compiled on Nov 26 2017 at 17:11:55 using Microsoft Visual C++ version 1900
2018-01-30T04:00:22.793095Z <001> 38 MB info | system information:
2018-01-30T04:00:22.793095Z <001> 38 MB info | architecture x86 64-bit
2018-01-30T04:00:22.793095Z <001> 38 MB info | logical cores 4
2018-01-30T04:00:22.793095Z <001> 38 MB info | L1 data cache size 32.0 KB, line size 64 bytes
2018-01-30T04:00:22.793095Z <001> 38 MB info | L2 cache size 256.0 KB, line size 64 bytes
2018-01-30T04:00:22.793095Z <001> 38 MB info | L3 cache size 3.0 MB, line size 64 bytes
2018-01-30T04:00:22.793095Z <001> 38 MB info | instruction sets sse sse2 sse3 ssse3 sse4.1 sse4.2 avx avx2 fma3
2018-01-30T04:00:22.793095Z <001> 38 MB info | physical memory size 7.8 GB
2018-01-30T04:00:22.793095Z <001> 38 MB info | virtual memory size 9.1 GB
2018-01-30T04:00:22.808324Z <001> 39 MB info | successfully loaded settings from H:\appleseed\settings\appleseed.studio.xml.
2018-01-30T04:00:22.833572Z <002> 40 MB info | loading project file H:\task5\appleseed\samples\cpp\sphereobject\sphereobject.appleseed...
2018-01-30T04:00:22.834574Z <002> 41 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of aov plugins...
2018-01-30T04:00:22.834574Z <002> 41 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed aov plugin because it does not export a appleseed_create_aov_factory() function.
2018-01-30T04:00:22.834574Z <002> 41 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.834574Z <002> 41 MB debug | .
2018-01-30T04:00:22.834574Z <002> 41 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of assembly plugins...
2018-01-30T04:00:22.834574Z <002> 41 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed assembly plugin because it does not export a appleseed_create_assembly_factory() function.
2018-01-30T04:00:22.850209Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.850209Z <002> 45 MB debug | .
2018-01-30T04:00:22.850209Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of bsdf plugins...
2018-01-30T04:00:22.853440Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed bsdf plugin because it does not export a appleseed_create_bsdf_factory() function.
2018-01-30T04:00:22.856381Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.856381Z <002> 45 MB debug | .
2018-01-30T04:00:22.857702Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of bssrdf plugins...
2018-01-30T04:00:22.860575Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed bssrdf plugin because it does not export a appleseed_create_bssrdf_factory() function.
2018-01-30T04:00:22.862634Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.862634Z <002> 45 MB debug | .
2018-01-30T04:00:22.862634Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of camera plugins...
2018-01-30T04:00:22.864662Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed camera plugin because it does not export a appleseed_create_camera_factory() function.
2018-01-30T04:00:22.866668Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.866668Z <002> 45 MB debug | .
2018-01-30T04:00:22.866668Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of edf plugins...
2018-01-30T04:00:22.868840Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed edf plugin because it does not export a appleseed_create_edf_factory() function.
2018-01-30T04:00:22.871277Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.871277Z <002> 45 MB debug | .
2018-01-30T04:00:22.871353Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of environment edf plugins...
2018-01-30T04:00:22.873604Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed environment edf plugin because it does not export a appleseed_create_environment_edf_factory() function.
2018-01-30T04:00:22.879124Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.879124Z <002> 45 MB debug | .
2018-01-30T04:00:22.879624Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of environment shader plugins...
2018-01-30T04:00:22.882129Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed environment shader plugin because it does not export a appleseed_create_environment_shader_factory() function.
2018-01-30T04:00:22.883634Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.883634Z <002> 45 MB debug | .
2018-01-30T04:00:22.883634Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of light plugins...
2018-01-30T04:00:22.886140Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed light plugin because it does not export a appleseed_create_light_factory() function.
2018-01-30T04:00:22.888147Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.888147Z <002> 45 MB debug | .
2018-01-30T04:00:22.888194Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of material plugins...
2018-01-30T04:00:22.893867Z <002> 45 MB debug | shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll is not an appleseed material plugin because it does not export a appleseed_create_material_factory() function.
2018-01-30T04:00:22.895887Z <002> 45 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.895887Z <002> 45 MB debug | .
2018-01-30T04:00:22.895887Z <002> 45 MB debug | scanning H:\task5\appleseed\samples\cpp\sphereobject\build\Release in search of object plugins...
2018-01-30T04:00:22.898915Z <002> 46 MB info | registering object plugin H:\task5\appleseed\samples\cpp\sphereobject\build\Release\infiniteplaneobject.dll...
2018-01-30T04:00:22.899917Z <002> 46 MB debug | could not open shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll: Cannot load shared library H:\task5\appleseed\samples\cpp\sphereobject\build\Release\sphereobject.dll. Error = The specified module could not be found.
2018-01-30T04:00:22.899917Z <002> 46 MB debug | .
2018-01-30T04:00:22.899917Z <002> 46 MB debug | scanning H:\task5\

Sean (Jan 30 2018 at 04:05):

next try this: find_library(BRLCAD_BU_LIBRARY bu PATHS H:/BRLCAD7.26.0/lib NO_DEFAULT_PATH)

Sean (Jan 30 2018 at 04:06):

and use ${BRLCAD_BU_LIBRARY} instead of that H:\\BRLCAD... path in target_link_libraries

Sean (Jan 30 2018 at 04:07):

Mitesh (Jan 30 2018 at 04:09):

Mitesh (Jan 30 2018 at 04:10):

Sean (Jan 30 2018 at 04:12):

okay, so just truncated ... the printing at the end is really curious given the general module load failure message

Sean (Jan 30 2018 at 04:13):

lets see if getting rid of the full-path changes anything, and (assuming it does nothing) confirm what the log output is saying when you only comment out the bu_log line

Mitesh (Jan 30 2018 at 04:17):

Please set them or make sure they are set and tested correctly in the CMake files:
2> BRLCAD_BU_LIBRARY

Mitesh (Jan 30 2018 at 04:17):

2> -- Configuring incomplete, errors occurred!
2>CUSTOMBUILD : CMake error : The following variables are used in this project, but they are set to NOTFOUND.
2> Please set them or make sure they are set and tested correctly in the CMake files:
2> BRLCAD_BU_LIBRARY
2> linked by target "sphereobject" in directory H:/task5/appleseed/samples/cpp/sphereobject

Sean (Jan 30 2018 at 04:18):

Mitesh (Jan 30 2018 at 04:23):

Sean (Jan 30 2018 at 04:24):

so that worked? interesting (windows doesn't care any more, cmake must be dorking with them somehow)

Mitesh (Jan 30 2018 at 04:24):

1>CUSTOMBUILD : CMake error : The following variables are used in this project, but they are set to NOTFOUND.
1> -- Configuring incomplete, errors occurred!
1> See also "H:/task5/appleseed/samples/cpp/sphereobject/build/CMakeFiles/CMakeOutput.log".
1> Please set them or make sure they are set and tested correctly in the CMake files:
1> BRLCAD_BU_LIBRARY
1> linked by target "sphereobject" in directory H:/task5/appleseed/samples/cpp/sphereobject
1>
1> CMake Configure step failed. Build files cannot be regenerated correctly. Attempting to stop IDE build.
2>------ Build started: Project: sphereobject, Configuration: Release x64 ------
2> Building Custom Rule H:/task5/appleseed/samples/cpp/sphereobject/CMakeLists.txt
2> CMake is re-running because H:/task5/appleseed/samples/cpp/sphereobject/build/CMakeFiles/generate.stamp is out-of-date.
2> the file 'H:/task5/appleseed/samples/cpp/sphereobject/CMakeLists.txt'
2> is newer than 'H:/task5/appleseed/samples/cpp/sphereobject/build/CMakeFiles/generate.stamp.depend'
2> result='-1'
2> -- Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.16299.
2> -- Boost version: 1.55.0
2>CUSTOMBUILD : CMake error : The following variables are used in this project, but they are set to NOTFOUND.
2> -- Configuring incomplete, errors occurred!
2> See also "H:/task5/appleseed/samples/cpp/sphereobject/build/CMakeFiles/CMakeOutput.log".
2> Please set them or make sure they are set and tested correctly in the CMake files:
2> BRLCAD_BU_LIBRARY
2> linked by target "sphereobject" in directory H:/task5/appleseed/samples/cpp/sphereobject
2>
========== Build: 0 succeeded, 2 failed, 0 up-to-date, 0 skipped ==========

Sean (Jan 30 2018 at 04:25):

er, so then what did you actually "confirm"? because that output is saying the same thing

Mitesh (Jan 30 2018 at 04:26):

Sean (Jan 30 2018 at 04:26):

Mitesh (Jan 30 2018 at 04:27):

Sean (Jan 30 2018 at 04:27):

Sean (Jan 30 2018 at 04:28):

you'll need to read the CMakeFiles/CMakeError.log file and/or the CMakeOutput.log file to see what they say about libbu

Mitesh (Jan 30 2018 at 04:35):

Sean (Jan 30 2018 at 04:35):

Mitesh (Jan 30 2018 at 04:36):

I mean all is going above the head...(not understanding much in CMakeOutput.log)

Sean (Jan 30 2018 at 04:37):

Mitesh (Jan 30 2018 at 04:40):

Sean (Jan 30 2018 at 04:41):

er, you're possibly looking in the wrong directory then .. there should be an error log in path/to/builddir/CMakeFiles/.

Sean (Jan 30 2018 at 04:42):

Mitesh (Jan 30 2018 at 04:43):

Mitesh (Jan 30 2018 at 04:45):

Sean (Jan 30 2018 at 04:46):

Sean (Jan 30 2018 at 04:47):

Mitesh (Jan 30 2018 at 04:47):

Sean (Jan 30 2018 at 04:47):

okay, any time you edit CMakeLists.txt .. you MUST re-run cmake, configure, generate

Sean (Jan 30 2018 at 04:47):

Mitesh (Jan 30 2018 at 04:48):

Sean (Jan 30 2018 at 04:48):

there's no telling which of the changes we've made have worked or not if you've not been doing that :)

Mitesh (Jan 30 2018 at 04:50):

Ok my today's quota is over(i have exams)....will update you tommorrow...after i rerun the cmake and whole.....thank you so much....good night

Sean (Jan 30 2018 at 04:50):

Sean (Jan 30 2018 at 04:51):

Mitesh (Jan 30 2018 at 04:52):

Mitesh (Jan 30 2018 at 04:53):

Sean (Jan 30 2018 at 04:53):

sort of ... running cmake is kind of simple, but I can see how not knowing that you need to run it whenever you change a build file might be a new concept

Mitesh (Jan 30 2018 at 04:54):

Mitesh (Jan 30 2018 at 04:55):

Sean (Jan 30 2018 at 04:55):

Jeff Sieu (Jan 30 2018 at 16:22):

I tried to initialize ids to 0, but seems like I can't assign a scalar to an unordered_map. And something bazaar happens when I attempt to run this anyway, with next initialized to 0: I get logged out of Ubuntu.

Daniel Rossberg (Jan 30 2018 at 19:02):

BTW, CMake usually doesn't need to be called explicitly if the project files are generated once. Make or Visual Studio call cmake if they detect a change in the CMakeLists.txt files.

Mitesh (Jan 31 2018 at 03:10):

Mitesh (Jan 31 2018 at 03:12):

Mitesh (Jan 31 2018 at 03:15):

Daniel Rossberg (Jan 31 2018 at 13:14):

Should I build this first?

??? It's part of the sources. Copy the BRL-CAD directory in your AppleSeed plugin source directory, include it with add_subdirectory(BRL-CAD) in your CMakeLists.txt and refer to it with "brlcad" and "BRLCAD_INCLUDE_DIR" like any other sublibrary (see https://github.com/drossberg/BrlCadQtGUI/blob/master/src/CMakeLists.txt for example).

Sean (Feb 01 2018 at 03:29):

@Jeff Sieu you can, you just need to be using c++11, but... the important one is initializing next to 0... try running in valgrind or in gdb if it's logging you out

Sean (Feb 01 2018 at 03:37):

Sean (Feb 01 2018 at 03:38):

Interesting... I've never been able to fully reliably trust that to work right on windows

Mitesh (Feb 03 2018 at 13:08):

Hey...sorry guys... I am little busy with my exams...will update my work on 14th/15th feb

Jeff Sieu (Feb 03 2018 at 13:45):

Parth Pandya (Feb 05 2018 at 12:28):

Sean (Feb 05 2018 at 17:06):

@Jeff Sieu if you need help with debugging, how to use a debugger, just ask... the basics with gdb is to just run a program like you normally would, but then prepend "gdb --args" to the command line, then "run" at the gdb prompt

Denis Pavlov (May 22 2018 at 17:48):

@Sean , hello. I have been trying to deal with Appleseed dependencies for a few days already and now I am kind of stuck, so I wanted to ask for advice.
First of all, what I have done at this point: I have added "apprt" command to "mged_cmdtab" and created a callback function for it in .c file.
1) Then, I tried to use Appleseed as it is without tclscripts and all this stuff. I have added all the necessary libs to cmake file and a few appleseed includes to the .c file. When I try to build it I get "cstddef: No such file or directory" error. Probably it happens because of name mangling, since mged is compiled with c99 and Appleseed with c++11. Well, that's not surprising.
2) Then I created a .cpp file, compiled in with c++ compiler(it builds okay, without any errors) and tried to call it using extern "C" mechanism from .c file, but I still got some linking errors.
Am I doing something wrong? What's a proper way to do this?
P.S. I am working on Ubuntu 16.04

Sean (May 27 2018 at 18:30):

@Denis Pavlov 1) sounds like you need to rename your source file to .cpp so it compiles as c++... cstddef is not a valid header for a .c file.

Sean (May 27 2018 at 18:31):

which it sounds like you figured out in 2) but you got things reversed -- you extern "C" in the .cpp file, and then just declare and call the function in a .c files

Sean (May 27 2018 at 18:31):

Jeffrey Liu (Dec 14 2019 at 19:47):

It looks like it looks for BRLCAD through my PATH environment variable (although I'm not quite sure how) in order to find BRLCAD, which should means that I should be able to use it externally, right?

starseeker (Dec 14 2019 at 20:03):

@Jeffrey Liu It should work, yes - it's a bit heavy for what you need, but if that's easier there's no reason not to use it

Jeffrey Liu (Dec 14 2019 at 20:05):

Alright, thanks so much for the help! I will try doing it now and see how it works.

starseeker (Dec 14 2019 at 20:05):

The simplest thing would be to explicitly supply the .so file paths to target_link_libraries, although that's poor practice for any general use code

Jeffrey Liu (Dec 14 2019 at 20:05):

starseeker (Dec 14 2019 at 20:05):

wait - by use, do you mean cut/paste into your code? You probably don't want to do that

starseeker (Dec 14 2019 at 20:06):

Jeffrey Liu (Dec 14 2019 at 20:07):

Actually, I'm not sure how I wanted to use it. All I really wanted to do was to properly link the librt headers and such so that I could call the proper functions from the appleseed code.

Jeffrey Liu (Dec 14 2019 at 20:07):

It definitely seems like there are some components that wouldn't be necessary for my purposes

starseeker (Dec 14 2019 at 20:08):

if you want to use the FindBRLCAD.cmake file, take a look at what rt^3 does in its main CMakeLists.txt file - you should be able to call it the same way

starseeker (Dec 14 2019 at 20:09):

@Jeffrey Liu I think Daniel posted a question for you over in the Appleseed channel...

Jeffrey Liu (Dec 14 2019 at 20:11):

Sorry, where? I believe I responded to everything that has been directed towards me.

starseeker (Dec 14 2019 at 20:11):

Jeffrey Liu (Dec 14 2019 at 20:14):

Oh, yes, he asked me what exactly I was trying to do with the BRLCAD libraries and I think I responded accordingly. He pointed me towards the dll_devel.zip but after compiling a test it seems like it might be easier to directly link what I need.

starseeker (Dec 14 2019 at 20:16):

starseeker (Dec 14 2019 at 20:18):

I'll confess I usually do this sort of thing inside BRL-CAD proper, where we have extensive wiring in place for building across multiple platforms... I'd probably just make an "art" executable in src/rt using the existing rt CMake as a template, then add in any needed Appleseed logic. However, that's easier for me since I've been working with that build system for years - it's a lot to take in for a brand new user.

starseeker (Dec 14 2019 at 20:19):

To link BRL-CAD and Appleseed you'd probably want a FindAppleseed.cmake file (we have many similar files in misc/CMake)

Jeffrey Liu (Dec 14 2019 at 20:21):

Creating some sort of "art" executable in src/rt does seem like the end goal in mind for this task set; my apologies for forgetting to mention that I'm working on a specific task, which requires me to call rt_shootray() from an appleseed program.

starseeker (Dec 14 2019 at 20:22):

Jeffrey Liu (Dec 14 2019 at 20:22):

I believe that the purpose of this task is to first integrate BRLCAD into appleseed, whereas later tasks are meant to integrate appleseed into BRLCAD

Jeffrey Liu (Dec 14 2019 at 20:23):

It's alright, your advice is very insightful! I'll be sure to keep it in mind for the later tasks.

Jeffrey Liu (Dec 14 2019 at 20:27):

That said, for this specific task, would using part of the example FindBRLCAD.cmake file be enough to configure the appleseed program to call functions from librt? I'm not really sure which parts are necessary and which parts aren't.

starseeker (Dec 14 2019 at 20:28):

FindBRLCAD.cmake, if it finds BRL-CAD, will define a series of CMake variables that can then be used in the include_directories and target_link_libraries lines.

starseeker (Dec 14 2019 at 20:30):

I'd go ahead and experiment a bit - just bear in mine if you start cutting up the FindBRLCAD.cmake file that it's using loops, lists, and a lot of other logic that will make it somewhat harder to digest.

If you want to use it "as is" you should be able to call it the way rt^3 calls it (find_package most likely) and just use what it gives you

starseeker (Dec 14 2019 at 20:31):

@Jeffrey Liu Depending on how the task is defined, doing it manually in Visual Studio may be enough for the task

starseeker (Dec 14 2019 at 20:32):

Elaborate CMake work is only warranted if we're wiring Appleseed into BRL-CAD - going the other way I'd imagine anything that works is fine for a start-up task...

Jeffrey Liu (Dec 14 2019 at 20:34):

Hm, it's true that the task itself doesn't specify how I should be linking BRLCAD, and I assume that the CMake work involved between linking Appleseed into BRLCAD is probably a little different compared to linking BRLCAD into Appleseed.

starseeker (Dec 14 2019 at 20:35):

Either way CMake sounds like it's a distraction from the point of this task, so if manually setting it up in Visual Studio works I'd go with it.

Jeffrey Liu (Dec 14 2019 at 20:35):

Jeffrey Liu (Dec 14 2019 at 20:38):

I can see how I might set it up in Visual Studio - it would probably just be a matter of manually setting up the include and lib directories. However, if part of the task does indeed involve configuring CMake, then I guess I can always go back to it later.

starseeker (Dec 14 2019 at 20:39):

right. If you can get it working manually, you'll know you can eventually make the code work with CMake too and that way you can stay focused on the core Appleseed piece

Jeffrey Liu (Dec 14 2019 at 20:39):

starseeker (Dec 14 2019 at 20:40):

Jeffrey Liu (Dec 14 2019 at 20:42):

Sean (Dec 14 2019 at 21:28):

@Jeffrey Liu yes, the task intentionally does not say anything at all about the build system as it’s not the focus. The focus is strictly on the task objective.

Jeffrey Liu (Dec 14 2019 at 21:29):

Oh ok, that makes things a lot simpler. I believe that I've been able to link it correctly manually. As for the task objective itself, how should I be handling the hit/miss callbacks?

Jeffrey Liu (Dec 14 2019 at 21:29):

I believe that I'd need to use some obj or database, so could I load in a sphere.obj overlaying the SphereObject?

Sean (Dec 14 2019 at 21:30):

However you get it working is fine. I would recommend following the existing cmake in brl-cad or rt^3 as being the easiest and fastest but it still literally does not matter yet.

Jeffrey Liu (Dec 14 2019 at 21:35):

When I say overlay, I just mean load in a sphere object so that the rays from the brlcad raytracing have something to hit/miss. My plan was to, in both intersect() functions, call rt_shootray() with the identical ray information as the appleseed raytracing, and then print out statements within both the hit/miss callbacks.

Jeffrey Liu (Dec 15 2019 at 08:48):

Hi @Sean , I've been getting some strange errors from my program but I've been having a lot of difficulty debugging it. So after manually linking the required BRLCAD libraries (which I believe worked successfully, as compiling is successful), appleseed ends up crashing when I try to load in the project. It seems like this happens when bu_log(), bu_exit(), rt_prep_parallel(), and maybe other functions are called.

Jeffrey Liu (Dec 15 2019 at 08:49):

Some sort of document named (BRL-CAD)-15072-bomb is created, but all it contains is this:

******************************************

BRL-CAD Release 7.30.3  Crash Report
    Thu, 05 Dec 2019 17:18:30 -0500, Compilation 0
    JeffL@unknown

Command: (BRL-CAD)
Process: 15072
Path: C:\Users\JeffL\Downloads\Google Code-in 2019\Source\appleseed\sandbox\bin\vc141\Ship\appleseed.studio.exe
Date: Sun Dec 15 03:40:46 2019

Call stack backtrace (thread 0):

Sumagna Das (Dec 15 2019 at 08:49):

Jeffrey Liu (Dec 15 2019 at 08:49):

Sumagna Das (Dec 15 2019 at 08:50):

Jeffrey Liu (Dec 15 2019 at 08:51):

Sumagna Das (Dec 15 2019 at 08:52):

Sumagna Das (Dec 15 2019 at 08:53):

Jeffrey Liu (Dec 15 2019 at 08:53):

Have you linked the materal to the sphere instance? Did you rerender the image afterwards?

Jeffrey Liu (Dec 15 2019 at 08:54):

You might also want to add in a couple other objects, as after the materials are set up properly, the render will be completely dark without any lights.

Jeffrey Liu (Dec 15 2019 at 08:57):

Back to what I was saying, it seems like rt_dirbuild() passes through without error as I was able to print a test statement following the call to rt_dirbuild().

Sumagna Das (Dec 15 2019 at 08:57):

i right clicked on the sphere instance, pressed assign materials and assigned it the green material

Sumagna Das (Dec 15 2019 at 08:58):

sorry for the delay and interruption but my laptop's keyboard is kind of pressing 4 without my intervention

Jeffrey Liu (Dec 15 2019 at 08:59):

Sumagna Das (Dec 15 2019 at 08:59):

Jeffrey Liu (Dec 15 2019 at 09:00):

Could you send over your appleseed file then? It'll be easier for me to see your setup.

Sumagna Das (Dec 15 2019 at 09:01):

Sumagna Das (Dec 15 2019 at 09:02):

Jeffrey Liu (Dec 15 2019 at 09:04):

After running appleseed through the VS debugger mode, this is what happens when I attempt to load in the plugin:

Exception thrown at 0x00007FFE0B32A839 in appleseed.studio.exe: Microsoft C++ exception: xercesc_3_2::TraverseSchema::ExceptionCodes at memory location 0x0000002BA4EFDEF0.
'appleseed.studio.exe' (Win32): Loaded 'C:\Users\JeffL\Downloads\Google Code-in 2019\Source\appleseed\sandbox\examples\cpp\art\build\Release\art-plugin.dll'. Module was built without symbols.
'appleseed.studio.exe' (Win32): Unloaded 'C:\Users\JeffL\Downloads\Google Code-in 2019\Source\appleseed\sandbox\examples\cpp\art\build\Release\art-plugin.dll'
Exception thrown at 0x00007FFE0B32A839 in appleseed.studio.exe: Microsoft C++ exception: foundation::ExceptionCannotLoadSharedLib at memory location 0x0000002BA4EFDF48.

Jeffrey Liu (Dec 15 2019 at 09:10):

@Sumagna Das Alright, so what it seems to me is that, if you look at the sphere instance itself, there is no material assigned to the "back," and since your camera position is starting inside of the sphere, it is still indicating that there is no material.

Jeffrey Liu (Dec 15 2019 at 09:12):

It's getting late for me so I'm going to head off for now. Have a nice night (or day)!

Sumagna Das (Dec 15 2019 at 09:12):

Jeffrey Liu (Dec 15 2019 at 09:13):

This error is giving me quite the headache... I'm still having difficulty even understanding what exactly is causing the error.

Sumagna Das (Dec 15 2019 at 09:15):

Jeffrey Liu (Dec 15 2019 at 09:15):

Not necessarily, you just need to zoom out enough and the image should turn black (no lights)

Sumagna Das (Dec 15 2019 at 09:16):

Jeffrey Liu (Dec 15 2019 at 09:17):

To be honest I don't remember off the top of my head, but it's one of the first things mentioned in the "getting started" appleseed documentation.

starseeker (Dec 15 2019 at 14:06):

Based on that VS message, you're building in Release mode rather than Debug mode

Thusal Ranawaka (Dec 15 2019 at 14:11):

Thusal Ranawaka (Dec 15 2019 at 14:33):

Chiranjiv Singh Malhi (Dec 15 2019 at 15:13):

d1.PNG d2.PNG Can anyone please help me , whenever i try to build the software i get these errors after following the steps of installation. many of the programs are built but the main mged or archer are not made.

Himanshu (Dec 15 2019 at 15:40):

Hey @Daniel Rossberg If I have to bind function in lua so is it also compulsory to implement function of nested class too ?

Himanshu (Dec 15 2019 at 15:41):

Jeffrey Liu (Dec 15 2019 at 16:10):

Hi @starseeker , thank you for pointing that out! I hadn't even realized it. However, even after building in Debug mode, I'm still getting this error:

Exception thrown at 0x00007FFE0B32A839 in appleseed.studio.exe: Microsoft C++ exception: xercesc_3_2::TraverseSchema::ExceptionCodes at memory location 0x0000008D3DCFE3C0.
'appleseed.studio.exe' (Win32): Loaded 'C:\Users\JeffL\Downloads\Google Code-in 2019\Source\appleseed\sandbox\examples\cpp\art\build\Debug\art-plugin.dll'. Symbols loaded.
'appleseed.studio.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'appleseed.studio.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'.
'appleseed.studio.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'appleseed.studio.exe' (Win32): Unloaded 'C:\Windows\System32\msvcp140d.dll'
'appleseed.studio.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'appleseed.studio.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'appleseed.studio.exe' (Win32): Unloaded 'C:\Users\JeffL\Downloads\Google Code-in 2019\Source\appleseed\sandbox\examples\cpp\art\build\Debug\art-plugin.dll'

starseeker (Dec 15 2019 at 16:17):

I think you need to run a backtrace or break on the exception, but it's been a while since I've done that in MSVC so I don't recall the details

Jeffrey Liu (Dec 15 2019 at 16:18):

When you say backtrace, are you referring to the callstack that visual studio provides?

starseeker (Dec 15 2019 at 16:19):

starseeker (Dec 15 2019 at 16:20):

The message you posted indicates it's gotten an exception and talks about loading dlls, but doesn't give you any history from the source code of how you got to that point

starseeker (Dec 15 2019 at 16:21):

I usually develop on Linux, so I'm not terribly good at debugging on Windows, but one thing I know you can do is set breakpoints and single step through the code if need be.

Jeffrey Liu (Dec 15 2019 at 16:22):

Hm... this is quite an interesting situation because when debugging appleseed, it opens the appleseed.studio application from which I must load in the project file, which is where the issue arises.

Jeffrey Liu (Dec 15 2019 at 16:28):

If you're referring to the issue with the dll, that's the appleseed plugin that I compiled which is causing the issue.

Daniel Rossberg (Dec 15 2019 at 16:49):

Exception thrown at 0x00007FFE0B32A839 in appleseed.studio.exe: Microsoft C++ exception: xercesc_3_2::TraverseSchema::ExceptionCodes at memory location 0x0000002BA4EFDEF0.
'appleseed.studio.exe' (Win32): Loaded 'C:\Users\JeffL\Downloads\Google Code-in 2019\Source\appleseed\sandbox\examples\cpp\art\build\Release\art-plugin.dll'. Module was built without symbols.
'appleseed.studio.exe' (Win32): Unloaded 'C:\Users\JeffL\Downloads\Google Code-in 2019\Source\appleseed\sandbox\examples\cpp\art\build\Release\art-plugin.dll'
Exception thrown at 0x00007FFE0B32A839 in appleseed.studio.exe: Microsoft C++ exception: foundation::ExceptionCannotLoadSharedLib at memory location 0x0000002BA4EFDF48.

The error message says it all: foundation::ExceptionCannotLoadSharedLib
The appleseed program possibly couldn't find the BRL-CAD DLLs. These are either the brlcad.dll or librt.dll, libbu.dll, etc., depending on which you linked. ropping them into the Appleseed binary directory is the simplest solution.

Jeffrey Liu (Dec 15 2019 at 16:51):

My understanding was that the DLL it was referring to was art-plugin.dll, which was my program/plugin. I thought that I statically linked the BRLCAD libraries through the .lib files.

Jeffrey Liu (Dec 15 2019 at 16:52):

I was able to resolve the crashing by placing my geometry database in the proper directory - it seems like after failing to load in the database, the application would crash.

Jeffrey Liu (Dec 15 2019 at 16:55):

Looks like i have a new issue now... rendering ends up crashing the application instead now :(

Daniel Rossberg (Dec 15 2019 at 16:58):

This is not true. The .lib files contain the interface description only. If they belong to a .dll, these files are still necessary as they contain the byte code. Your art-plugin.dll cannot be loaded if they aren't present.

Jeffrey Liu (Dec 15 2019 at 17:01):

Oh, I wasn't aware of that. Would it not be enough to link the .lib files from the installation directory? I can't seem to find any .dll files there.

Daniel Rossberg (Dec 15 2019 at 17:02):

Jeffrey Liu (Dec 15 2019 at 17:03):

Oh I see them now, guess I didn't look hard enough. So should I just copy-paste the .dll files I need?

Daniel Rossberg (Dec 15 2019 at 17:03):

Daniel Rossberg (Dec 15 2019 at 17:04):

Jeffrey Liu (Dec 15 2019 at 17:05):

Sumagna Das (Dec 15 2019 at 18:16):

do i have to submit the screenshot of the output window of rt command in mged for the task appleseed #1(create and render a sphere in BRL-CAD and appleseed)?

Daniel Rossberg (Dec 15 2019 at 18:23):

Sumagna Das (Dec 15 2019 at 18:28):

Sumagna Das (Dec 15 2019 at 18:30):

Sumagna Das (Dec 15 2019 at 18:35):

Daniel Rossberg (Dec 15 2019 at 18:44):

I know this issue from Linux, but I couldn't find a solution yet. You can set the background color with the "-C" option (e.g. "-C 243/134/17"). But, it will still be transparent. Putting the window in front of the dark mged graphics window helps.

Another possibility is to use the "Raytrace Control Panel" from the "Tools" menu and render it into mged's graphics window.

Sumagna Das (Dec 15 2019 at 18:44):

Sumagna Das (Dec 15 2019 at 18:47):

Daniel Rossberg (Dec 15 2019 at 18:47):

I work on Linux and Windows. At the moment, I'm sitting in front of a Linux machine. But at work I'm developing with Visual Studio on Windows.

Jeffrey Liu (Dec 15 2019 at 18:47):

Sumagna Das (Dec 15 2019 at 18:48):

Sumagna Das (Dec 15 2019 at 18:50):

i have windows and ubuntu on dual boot as my father also takes this laptop to his work sometimes and he cant work with ubuntu

Jeffrey Liu (Dec 15 2019 at 18:57):

@Daniel Rossberg I tried what you told me to do and I believe it ended up working - thanks so much for all of your help!

Sumagna Das (Dec 15 2019 at 18:59):

hey jeffrey does the rendered version of the sphere needs to have a material or can it be pink(without material) for the appleseed #1 task?

Jeffrey Liu (Dec 15 2019 at 19:01):

When I was doing the task, I was told that the main point of the task was just to figure out how to convert a geometry database into an obj file and then import it into appleseed - the materials were not necessarily important. That said, I ended up giving it a material and added lights so that it felt more complete.

Sumagna Das (Dec 15 2019 at 19:01):

Sumagna Das (Dec 15 2019 at 19:02):

Sumagna Das (Dec 15 2019 at 19:03):

Jeffrey Liu (Dec 16 2019 at 20:40):

Hi @Sean , I'm just getting started on task #6 of Appleseed. If I'm interpreting correctly, is the point of this task to detect the geometry database information with BRLCAD and then provide that information to Appleseed so that it can render it?

Jeffrey Liu (Dec 17 2019 at 00:22):

I'm getting a weird error when I call rt_shootray() too many times... the first time I got like a Debug Assertion Error with something related to debug_heap.cpp, and now appleseed is just crashing when I try to render with the plugin.

Erik (Dec 17 2019 at 00:29):

Jeffrey Liu (Dec 17 2019 at 00:30):

I think it might have something to do with a leak, but I'm not sure if I can do anything about it, because as far as I know it's getting caused by a function that I don't really have much control over.

Jeffrey Liu (Dec 17 2019 at 00:33):

I'm having a bit of trouble debugging it because I'm running appleseed.studio, and then the error comes when I try to render using the dll I compiled. Could you help me figure out how to properly debug it?

Jeffrey Liu (Dec 17 2019 at 04:32):

Reading the past chat, it seems like I have the same issue as Jeff - appleseed's threading vs brlcad's threading is causing the crash. I will see what I can do solve this.

Jeffrey Liu (Dec 17 2019 at 06:03):

I feel like I'm close... when I call ap_a_resource->re_cpu I'm getting outputs from 0-3, but rendering is still crashing.

Jeffrey Liu (Dec 17 2019 at 06:07):

Rendering is really inconsistent, one time a single tile got rendered before crashing. At least that means some sort of progress has been made though?

Sumagna Das (Dec 17 2019 at 06:37):

Jeffrey Liu (Dec 17 2019 at 06:39):

@Sumagna Das From what I can tell, VSET is used to set the origin and direction of the ray being shot, hence the ap.a_ray.r_dir and ap.a_ray.r_pt.

Sumagna Das (Dec 17 2019 at 06:39):

Sumagna Das (Dec 17 2019 at 06:40):

Jeffrey Liu (Dec 17 2019 at 06:41):

Update on my progress: it is indeed some sort of threading issue because when I use the appleseed command-line version and set the number of threads to only 1, rendering outputs an image although it's still not a correct image :(

Sean (Dec 17 2019 at 06:41):

Sumagna Das (Dec 17 2019 at 06:42):

Sean (Dec 17 2019 at 06:42):

Essentially yes, render a given bit of brl-cad geometry using librt, but from within appleseed (still using their procedural api)

Sean (Dec 17 2019 at 06:43):

if you spend more than a couple hours, just report out where you're at and what you have and don't have working, and we can think about where to go from there

Sumagna Das (Dec 17 2019 at 06:44):

Sumagna Das (Dec 17 2019 at 06:45):

Jeffrey Liu (Dec 17 2019 at 06:46):

Welp I've spent quite a few hours so far, so I guess I can report: similar to the issue Jeff was facing 2 years ago, appleseed still crashes when I try to render. It is definitely a threading issue because when I run appleseed.cli on a single thread, an image gets output (I still need to work on that). I'm not really sure where to go from here because I tried setting up the resources (and ap->a_resource->re_cpu outputs various ints) but it is still crashing.

Sean (Dec 17 2019 at 06:48):

It's setting the ray direction to a vector with i/j/k components set to 0.0, 0.0, -1.0 --- that is, the ray is pointing "down"

Sean (Dec 17 2019 at 06:48):

Sumagna Das (Dec 17 2019 at 06:48):

Sumagna Das (Dec 17 2019 at 06:49):

Jeffrey Liu (Dec 17 2019 at 06:49):

As for the rendering itself, I believe I'm transferring the ray information correctly, but there's quite a few things that I think could go wrong. For example, I'm returning ap->a_ray_length as the distance, but I have no idea if the units are even the same. Other things that I could be doing incorrectly are setting the UVs and the bounding box.

Sean (Dec 17 2019 at 06:49):

so this is like looking from a "top" view in mged (just type top or "t" in the graphics window)

Sumagna Das (Dec 17 2019 at 06:49):

Sean (Dec 17 2019 at 06:49):

Sumagna Das (Dec 17 2019 at 06:50):

so if i have to shoot a grid of rays i have to change x and y value to something else

Sumagna Das (Dec 17 2019 at 06:50):

Sean (Dec 17 2019 at 06:51):

@Jeffrey Liu there is a librt routine that will return the bounding box size (or you can call ged_bb() to get it more easily)

Sean (Dec 17 2019 at 06:52):

@Sumagna Das for that particular ray, you'd need to change r_pt to a bunch of different X and Y values (keeping Z at 10000)

Sumagna Das (Dec 17 2019 at 06:52):

Sumagna Das (Dec 17 2019 at 06:53):

Sean (Dec 17 2019 at 06:53):

Sumagna Das (Dec 17 2019 at 06:53):

Sean (Dec 17 2019 at 06:53):

Sumagna Das (Dec 17 2019 at 06:54):

Sean (Dec 17 2019 at 06:54):

tasks aren't hard for the sake of being hard ... use the source to help you understand

Sean (Dec 17 2019 at 06:54):

Sumagna Das (Dec 17 2019 at 06:54):

Sumagna Das (Dec 17 2019 at 06:55):

Sean (Dec 17 2019 at 06:55):

Sumagna Das (Dec 17 2019 at 06:56):

Sean (Dec 17 2019 at 06:56):

Sumagna Das (Dec 17 2019 at 06:56):

Jeffrey Liu (Dec 17 2019 at 06:56):

Would I need to include an extra header to call ged_bb()? It says that this function does not exist at the moment.

Sean (Dec 17 2019 at 06:57):

it can, but then you're changing the direction of the ray. that's not probably something you want to do at this point, but should try to understand

Sumagna Das (Dec 17 2019 at 06:57):

Sean (Dec 17 2019 at 06:57):

Sumagna Das (Dec 17 2019 at 06:57):

Jeffrey Liu (Dec 17 2019 at 06:58):

As for this issue @Sean , would it be alright if I rendered on a single thread for this task?

Thusal Ranawaka (Dec 17 2019 at 07:19):

Jeffrey Liu (Dec 18 2019 at 02:15):

I feel like I'm so close to rendering the .g file (still on a single thread though)... This is what I have so far (rendering sphere.g) pasted image

Jeffrey Liu (Dec 18 2019 at 02:16):

As of right now, the two biggest issues I'm facing are the UVs and the viewport.

Jeffrey Liu (Dec 18 2019 at 02:19):

I believe there is a component to the appleseed result that requires the object's UV coordinate at the point where the ray intersects it, but I'm struggling to find if/where this is stored through BRLCAD raytracing. I'm like 70% sure that's what's causing the weird visual bug on the sphere because I'm currently using the UV calculations done by the example sphereobject.

Jeffrey Liu (Dec 18 2019 at 02:25):

The other issue I'm facing is the viewport, as the traditional appleseed viewport mechanics (rotating, scrolling, zooming) have some really weird effects when I try to do it when rendering the geometry. My best guess, which might be totally wrong, is that there's some sort of discrepancy between BRLCAD and appleseed in terms of perspective/orthographic projection. I believe appleseed uses perspective projection while BRLCAD uses orthographic projection, but I'm not sure exactly how that would affect the result and I couldn't test the difference because I haven't figured out how to change the setting for either one.

Jeffrey Liu (Dec 18 2019 at 02:27):

Sean (Dec 18 2019 at 02:28):

Jeffrey Liu (Dec 18 2019 at 02:29):

Jeffrey Liu (Dec 18 2019 at 02:30):

An update on the visual glitch: it might not be a result of the UVs, since I hardcorded the coordinates to (1.0, 1.0) given that the object should just be a solid color, but the artifacts still exist.

Sean (Dec 18 2019 at 03:40):

@Jeffrey Liu hm, yeah, my first thought on the X pattern is that it's either UVs or input/output hit ordering

Jeffrey Liu (Dec 18 2019 at 03:41):

Sean (Dec 18 2019 at 03:41):

Sean (Dec 18 2019 at 03:42):

if the intersection callback is using the wrong point, you could be looking at the "inside" of the sphere in parts

Sean (Dec 18 2019 at 03:42):

Jeffrey Liu (Dec 18 2019 at 03:45):

I did consider that as a possible source of error, but I set ap->a_onehit = 1 (is that the correct way to stop the ray after the first intersection?). It might still be the case where the ray somehow just passes through the front of the object and hits the back of the object though.

Sean (Dec 18 2019 at 03:47):

it is the correct way, but multiple points can still be returned so you have to make sure you're using the in_hit, not the out_hit of the partition

Sean (Dec 18 2019 at 03:48):

as you're shooting a sphere, in and out points are calculated simultaneously, so a_onehit doesn't really do anything.

Jeffrey Liu (Dec 18 2019 at 03:49):

Oh I didn't know that, thanks for the insight! However, I'm pretty sure I'm using the in_hit (hitp = pp->pt_inhit;) correctly?

Sean (Dec 18 2019 at 03:50):

Jeffrey Liu (Dec 18 2019 at 03:51):

Hm, then it might be another issue. Could I send you the code that I have right now? Perhaps there's some glaring error that I've failed to notice.

Sean (Dec 18 2019 at 03:51):

Jeffrey Liu (Dec 18 2019 at 03:52):

Jeffrey Liu (Dec 18 2019 at 03:53):

I'm not really sure if the struct I made would be the best solution for what I'm doing, but it works for the time being I think.

Sean (Dec 18 2019 at 03:59):

Jeffrey Liu (Dec 18 2019 at 04:00):

Jeffrey Liu (Dec 18 2019 at 04:01):

Sean (Dec 18 2019 at 04:02):

Jeffrey Liu (Dec 18 2019 at 04:03):

Sean (Dec 18 2019 at 04:04):

but yeah, this is a hard task and even then you've still gone beyond the required with some parts needed for parallel (though looks like you have a bug there)

Sean (Dec 18 2019 at 04:04):

Sean (Dec 18 2019 at 04:05):

you can submit and it's good enough for #6 but probably not enough for the later task where you create an appleseed renderer

Jeffrey Liu (Dec 18 2019 at 04:05):

Yeah, rendering using multithreading still ended up crashing. I asked Franz about it and he told me:

indeed
there's just no way around it, if you want to render on multiple threads, whatever code you call in intersect() must be thread-safe, by definition
unless you add a lock in intersect(), but then performance will suffer, possibly quite dramatically

Jeffrey Liu (Dec 18 2019 at 04:07):

Ok thank you :) I will do that and then try to figure out what's causing the error. Would you still want me to include the render with the visual bug?

anshu khare (Dec 18 2019 at 04:08):

Sean (Dec 18 2019 at 04:08):

rt_shootray() is thread-safe, so it can be made to work, you just not doing the right initialization and the id method might need some help

Sean (Dec 18 2019 at 04:08):

anshu khare (Dec 18 2019 at 04:09):

Sean (Dec 18 2019 at 04:09):

it doesn't look like your problem has anything to do with appleseed. you should post on a different subject in #Google Code-in

Jeffrey Liu (Dec 18 2019 at 04:11):

Maybe it's the way I'm accessing/setting the information? I'm not very familiar with threading but perhaps it's because of the way I'm setting ap->a_ray.r_dir and ap->a_ray.r_pt in intersect().

Sean (Dec 18 2019 at 04:11):

Sean (Dec 18 2019 at 04:12):

Jeffrey Liu (Dec 18 2019 at 04:13):

I might be remembering incorrectly, but I thought ap->a_ray.m_dir only used normalized vectors.

Jeffrey Liu (Dec 18 2019 at 04:14):

So I asked the same question to the appleseed discord, and the best explanation I got was: the SIMPLE one returns a boolean used for shadow rays, where you only need to know if the ray was blocked, while the DETAILED one is used for all other rays where more information (hit point, normal, etc) are necessary.

Jeffrey Liu (Dec 18 2019 at 04:19):

^^ that's why for the SIMPLE method, i just checked the return of rt_shootray() to see if it was a hit or miss.

Sean (Dec 18 2019 at 04:24):

Sean (Dec 18 2019 at 04:26):

your brlcad_hit routine seems peculiar. don't know for sure without stepping through a test, but I don't think you need or want to iterate over partitions. you just want the hit point returned.

Sean (Dec 18 2019 at 04:27):

also, you calculate and stash the normal, but you probably shouldn't - you can do that in intersect() after rt_shootray() only if it's successful

Sean (Dec 18 2019 at 04:30):

Jeffrey Liu (Dec 18 2019 at 04:30):

Ah that makes sense, I should've looked at it more carefully - most of my hit call was taken from the rtexample method.

Sean (Dec 18 2019 at 04:31):

there should be only one partition with a simple sphere, but easy enough to test

Sean (Dec 18 2019 at 04:31):

yeah, rtexample iterates over everything because it's going to print all the hit information

Sean (Dec 18 2019 at 04:31):

Jeffrey Liu (Dec 18 2019 at 04:32):

Alright I'll try that, thanks for the advice! To be honest I wasn't really aware of what exactly the purpose of the loop was beforehand.

Jeffrey Liu (Dec 18 2019 at 04:33):

As for the normals, wouldn't it only be called in the hit callback, meaning that rt_shootray() is successful? Unless I'm neglecting to account for something?

Sean (Dec 18 2019 at 04:37):

Sean (Dec 18 2019 at 04:38):

if there are multiple partitions, you'll end up stashing the last normal instead of the first because of the looping

Jeffrey Liu (Dec 18 2019 at 04:38):

Oh right. So the break should fix that issue. In this case the looping will never be needed, right?

Sean (Dec 18 2019 at 04:42):

Jeffrey Liu (Dec 18 2019 at 04:43):

Sean (Dec 18 2019 at 04:43):

Thusal Ranawaka (Dec 18 2019 at 04:44):

HELLO I submit my task yesterday noon so kindly request for review it whenever time you got.

Sean (Dec 18 2019 at 04:44):

@Thusal Ranawaka your comment has absolutely nothing to do with Appleseed, so you should be posting to a different topic

Jeffrey Liu (Dec 18 2019 at 04:45):

Sean (Dec 18 2019 at 04:48):

Jeffrey Liu (Dec 18 2019 at 04:48):

One question about local bounding boxes: I can see how a box might be computed in the case where there's a single lowest point and a single highest point, but how is this handled when the bounding box is exactly horizontal?

Sean (Dec 18 2019 at 04:51):

Jeffrey Liu (Dec 18 2019 at 04:51):

This is what was output: Local Bounding Box: (-1.000000, -1.000000, -1.000000) , (1.000000, 1.000000, 1.000000). I'm exactly sure if this is correct because the sphere has a radius of 0.4mm

Jeffrey Liu (Dec 18 2019 at 04:53):

Sorry, now that I think about it, I was just wondering how a bounding box is calculated and how it's used. I noticed that the appleseed AABB constructor only took in two vector arguments, but I don't understand how this is enough information to create a bounding box.

Jeffrey Liu (Dec 18 2019 at 04:54):

It's a bit irrelevant, but I was just curious. Maybe I am doing something incorrect with the bounding box?

Sean (Dec 18 2019 at 04:54):

Jeffrey Liu (Dec 18 2019 at 04:56):

Right, that's what I was thinking, where the box lengths would just be the differences between the vector components, but what about in cases where, for example, the min/max points only differ in a single component (one is directly above the other)?

Sean (Dec 18 2019 at 05:02):

that'd be a degenerate case, typically is detected or compensated elsewhere in graphics codes

Sumagna Das (Dec 18 2019 at 14:43):

anyways i saw task 7 of the appleseed series.(i am not gonna start it now but after and if i complete the previous tasks)

Jeffrey Liu (Dec 18 2019 at 14:57):

Regarding the changes I made with the loop - unfortunately, the render still output the visual bug. I asked Franz about it and he said it was likely the result of busted normals or self-intersections.

Jeffrey Liu (Dec 18 2019 at 14:58):

He gave me some tips on how I could check/fix these errors, so I'll try working on them soon.

Sean (Dec 19 2019 at 02:51):

@Jeffrey Liu that was why my second suggestion was to pull the normal setting outside of the hit routine

Sean (Dec 19 2019 at 02:52):

Jeffrey Liu (Dec 19 2019 at 03:34):

Hm, franz pointed me towards the "Override Shading" option to view the normals by themselves, which looks like this pasted image

Jeffrey Liu (Dec 19 2019 at 03:35):

They seem smooth and there aren't any inconsistencies where the actual artifacts are occurring, so perhaps the issue is caused by something else?

Sean (Dec 19 2019 at 03:35):

Sean (Dec 19 2019 at 03:36):

but that's pretty exciting. can you open an arbitrary .g file now? looked in the code like you can...

Sean (Dec 19 2019 at 03:37):

Jeffrey Liu (Dec 19 2019 at 03:37):

Sean (Dec 19 2019 at 03:37):

Jeffrey Liu (Dec 19 2019 at 03:42):

Hopefully the camera settings work out, there's still that issue with the viewport so it might be hard to actually focus on what I need to. I'm still rebuilding (I should really allow custom paths later), but I don't see why the geometry wouldn't load.

Sean (Dec 19 2019 at 03:43):

Sean (Dec 19 2019 at 03:44):

Jeffrey Liu (Dec 19 2019 at 03:44):

Sean (Dec 19 2019 at 03:45):

I suspect it's still something wrong with the hit points themselves in the intersect() function

Jeffrey Liu (Dec 19 2019 at 03:46):

Darn, looks like nothing is rendering but I'm not sure if it's because of the camera settings or because of the geometry loading.

Jeffrey Liu (Dec 19 2019 at 03:47):

Database title: BRL-GSI Paris Air Show Soviet HAVOC Helicopter
Configuring complete!
Local Bounding Box: (-760.000000, -8438.000000, -890.000000) , (19125.000000, 8398.000000, 5360.000000)
Local Bounding Box: (-760.000000, -8438.000000, -890.000000) , (19125.000000, 8398.000000, 5360.000000)
Local Bounding Box: (-760.000000, -8438.000000, -890.000000) , (19125.000000, 8398.000000, 5360.000000)
Local Bounding Box: (-760.000000, -8438.000000, -890.000000) , (19125.000000, 8398.000000, 5360.000000)
Local Bounding Box: (-760.000000, -8438.000000, -890.000000) , (19125.000000, 8398.000000, 5360.000000)

Sean (Dec 19 2019 at 03:47):

Sean (Dec 19 2019 at 03:48):

so probably camera settings. if it was anywhere near the sphere, you'd need to be zoomed way way out

Jeffrey Liu (Dec 19 2019 at 03:49):

Jeffrey Liu (Dec 19 2019 at 03:52):

well, I found something after changing the location of the camera from 10 all the way to 10000: pasted image

Jeffrey Liu (Dec 19 2019 at 03:52):

Jeffrey Liu (Dec 19 2019 at 03:54):

Jeffrey Liu (Dec 19 2019 at 03:55):

That's exciting though, I'm happy to see that at least part of my code worked properly :)

Sean (Dec 19 2019 at 04:07):

Sean (Dec 19 2019 at 04:09):

Sean (Dec 19 2019 at 04:10):

appleseed is using +Y up instead of +Z up, so you'll need to apply a 90-degree rotation when you open geometry

Jeffrey Liu (Dec 19 2019 at 04:11):

That too, but trying to do CTRL + RIGHT/LEFT/MIDDLE mouse is giving some really weird effects - it should just be rotating, panning, and zooming, but it's being affected in other ways as well for some reason.

Jeffrey Liu (Dec 19 2019 at 04:12):

Sean (Dec 19 2019 at 04:27):

there is a way, but it'll take me a sec to look it up. it's not important for now

Jeffrey Liu (Dec 19 2019 at 04:32):

Alright, I think the two main issues I have right now are the weird dark spots and the viewport controls (I'm positive that when I'm rendering .g, the rotating/panning/zooming feels much less intuitive than it did before, but I don't know what might be causing this)

Sean (Dec 19 2019 at 04:40):

Jeffrey Liu (Dec 19 2019 at 04:40):

Sean (Dec 19 2019 at 04:49):

@Jeffrey Liu it very well could be the default navigation method, could be a method that works to keep 'up' pointing up

Sean (Dec 19 2019 at 04:49):

Jeffrey Liu (Dec 19 2019 at 04:50):

Oh, so the issue involving the +y and +z might actually be causing the viewport issues as well?

Sean (Dec 19 2019 at 04:50):

Sean (Dec 19 2019 at 04:51):

a real simple test would be to simply swap your values being reported back to appleseed

Sean (Dec 19 2019 at 04:52):

Jeffrey Liu (Dec 19 2019 at 04:52):

Sean (Dec 19 2019 at 04:53):

Sean (Dec 19 2019 at 04:54):

so it becomes return asr::GAABB3(asr::GVector3(rtip->mdl_min[X], rtip->mdl_min[Z], -rtip->mdl_min[Y]),
asr::GVector3(rtip->mdl_max[X], rtip->mdl_max[Z], -rtip->mdl_max[Y]));

Jeffrey Liu (Dec 19 2019 at 04:56):

Sean (Dec 19 2019 at 04:56):

Sean (Dec 19 2019 at 05:02):

Jeffrey Liu (Dec 19 2019 at 05:03):

brlcad_ray_info.normal[0] = inormal[0];
brlcad_ray_info.normal[1] = inormal[2];
brlcad_ray_info.normal[2] = -inormal[1];

Sean (Dec 19 2019 at 05:03):

Sean (Dec 19 2019 at 05:05):

all of these should get tested and confirmed with something like the axis example model

Jeffrey Liu (Dec 19 2019 at 05:05):

Oops, it looks like the havoc object is now upside-down, but the controls are working normally again :)

Sean (Dec 19 2019 at 05:06):

Jeffrey Liu (Dec 19 2019 at 05:08):

Sean (Dec 19 2019 at 05:08):

Jeffrey Liu (Dec 19 2019 at 05:10):

Oops it looks like my normals are inverted now, but it's looking like this now: pasted image

Sean (Dec 19 2019 at 05:10):

Sean (Dec 19 2019 at 05:12):

Jeffrey Liu (Dec 19 2019 at 05:13):

I think so, when I first loaded the object it was completely pink but I fixed it by setting the back material to the same as the front. I took a look at the shading normals override and it did look a little odd to me

Sean (Dec 19 2019 at 05:13):

you should let it render higher quality for a bit, see how nice it can get in a couple minutes

Jeffrey Liu (Dec 19 2019 at 05:13):

Sean (Dec 19 2019 at 05:14):

Jeffrey Liu (Dec 19 2019 at 05:14):

brlcad_ray_info.normal[0] = inormal[0];
brlcad_ray_info.normal[1] = -inormal[2];
brlcad_ray_info.normal[2] = inormal[1];

Jeffrey Liu (Dec 19 2019 at 05:15):

This is what the overrided shading normals looks like, but to be honest I have no idea if this is correct or not: pasted image

Sean (Dec 19 2019 at 05:15):

Sean (Dec 19 2019 at 05:16):

Jeffrey Liu (Dec 19 2019 at 05:17):

When I use brlcad_ray_info.normal again, I'm just normalizing it before assigning it, so it might be something else?

Sean (Dec 19 2019 at 05:17):

Sean (Dec 19 2019 at 05:19):

Jeffrey Liu (Dec 19 2019 at 05:20):

Jeffrey Liu (Dec 19 2019 at 05:21):

That does seem to be the case: when I reload the project, the surfaces with normals that have no y-component are still rendering with a material while the rest become pink

Jeffrey Liu (Dec 19 2019 at 05:24):

brlcad_ray_info.normal[0] = inormal[0];
brlcad_ray_info.normal[1] = inormal[2];
brlcad_ray_info.normal[2] = -inormal[1];

But that's weird though, aren't I only inverting Y in this case while I've been inverting Z everywhere else?

Jeffrey Liu (Dec 19 2019 at 05:27):

Ok I'm starting a final render now, seems like it might take a while but it's looking quite promising.

Jeffrey Liu (Dec 19 2019 at 05:34):

Here it is in all of its "final" glory: render.png I wish I added a light source so the shading wouldn't be so flat...

Jeffrey Liu (Dec 19 2019 at 05:35):

It looks pretty good otherwise, except for that weird black triangle - I'll try to figure out what's causing it.

Sean (Dec 19 2019 at 05:37):

but yeah, looks like there's a couple errors, and that's almost certainly related to whatever is wrong on the sphere case

Jeffrey Liu (Dec 19 2019 at 05:37):

It looks like there's something weird with this normal specifically: pasted image

Jeffrey Liu (Dec 19 2019 at 05:42):

Sean (Dec 19 2019 at 05:43):

Sean (Dec 19 2019 at 05:47):

I bet it was the normals then, I think that makes sense -- since we use +Z up, the normals being returned would have been wrong per the camera. they needed to be rotated or the geometry needed to be rotated. curious. what if you restore inormal to 0/1/2 without negation, what's that do?

Sean (Dec 19 2019 at 05:48):

Jeffrey Liu (Dec 19 2019 at 05:49):

Yep it seems like the normals were the issue, this is what it looks like when I changed it back: pasted image

Sean (Dec 19 2019 at 05:49):

Jeffrey Liu (Dec 19 2019 at 05:50):

Sean (Dec 19 2019 at 05:50):

Sean (Dec 19 2019 at 05:51):

Sean (Dec 19 2019 at 05:52):

it's a little suspicious that appleseed is rendering it that dark, but not implausible

Jeffrey Liu (Dec 19 2019 at 05:52):

Sean (Dec 19 2019 at 06:06):

Jeffrey Liu (Dec 19 2019 at 06:09):

Thanks! Having everything finally come together (for the most part) is super satisfying.

Sean (Dec 19 2019 at 06:11):

Jeffrey Liu (Dec 19 2019 at 06:11):

Thanks so much for your help by the way :) I wasn't aware of the appleseed +Y up and BRLCAD +Z up at all, which ended up being the factor that was causing almost all of the errors.

Jeffrey Liu (Dec 19 2019 at 06:11):

Sean (Dec 19 2019 at 06:11):

yeah, appleseed's doing it wrong, but not surprising given which tools he typically integrates with ;)

Sean (Dec 19 2019 at 06:13):

movie industry obsessively uses +Y up as the focus is on the "screen" you're looking at, not the world behind the screen

Sean (Dec 19 2019 at 06:14):

CAD modeling industry pretty universally uses +Z for up as that makes the most sense for the geometry itself. it's the coordinate frame of the world in nearly all other contexts.

Jeffrey Liu (Dec 19 2019 at 06:14):

Ah, I see. I believe that OpenGL uses a similar coordinate system as well, right?

Sean (Dec 19 2019 at 06:14):

Sean (Dec 19 2019 at 06:15):

Jeffrey Liu (Dec 19 2019 at 06:15):

Some of the calculations do seem a little weird at times when the +Y is pointing up

Jeffrey Liu (Dec 19 2019 at 06:15):

Sean (Dec 19 2019 at 06:16):

Jeffrey Liu (Dec 19 2019 at 06:19):

Ok It's getting pretty late for me now, so I'm going to head off. I think I might do a couple other tasks before returning to appleseed #7, but I hope to finish the whole task set as soon as I can.

Jeffrey Liu (Dec 19 2019 at 06:19):

Sean (Dec 19 2019 at 06:19):

Jeffrey Liu (Dec 19 2019 at 15:25):

Sumagna Das (Dec 19 2019 at 15:37):

can anyone tell me why the build of appleseed is giving me errors( i am building it from the source for task 2)

Sumagna Das (Dec 19 2019 at 15:39):

Jeffrey Liu (Dec 19 2019 at 15:44):

Sumagna Das (Dec 19 2019 at 15:44):

Jeffrey Liu (Dec 19 2019 at 15:59):

Sumagna Das (Dec 19 2019 at 15:59):

Sumagna Das (Dec 19 2019 at 16:01):

Sumagna Das (Dec 19 2019 at 16:09):

Jeffrey Liu (Dec 19 2019 at 16:12):

Sumagna Das (Dec 19 2019 at 16:12):

Jeffrey Liu (Dec 19 2019 at 16:13):

It seems like that line is pretty important, commenting it out will probably lead to some unwanted effects

Sumagna Das (Dec 19 2019 at 16:13):

Jeffrey Liu (Dec 19 2019 at 16:14):

Sumagna Das (Dec 19 2019 at 16:15):

Sumagna Das (Dec 19 2019 at 16:16):

Sumagna Das (Dec 19 2019 at 16:17):

Sumagna Das (Dec 19 2019 at 16:18):

Jeffrey Liu (Dec 20 2019 at 01:17):

Hmm... going off the "files in some directories in conflict with libraries in implicit directories," I think that means you already have an installed version of said library.

Sumagna Das (Dec 21 2019 at 19:05):

Sumagna Das (Dec 22 2019 at 15:25):

hey @Sean am i supposed to achieve something similar to the appleseed #2 in appleseed #3 task? (lika black and white image or something)

Sumagna Das (Dec 22 2019 at 15:26):

Sumagna Das (Dec 22 2019 at 15:59):

Sumagna Das (Dec 22 2019 at 16:00):

Sumagna Das (Dec 22 2019 at 16:06):

Jeffrey Liu (Dec 22 2019 at 16:10):

Jeffrey Liu (Dec 22 2019 at 16:12):

Sumagna Das (Dec 22 2019 at 16:16):

Thusal Ranawaka (Dec 22 2019 at 16:20):

Thusal Ranawaka (Dec 22 2019 at 16:22):

Jeffrey Liu (Dec 22 2019 at 16:24):

Jeffrey Liu (Dec 22 2019 at 16:40):

Vikramaditya Singh (Dec 22 2019 at 16:43):

Thusal Ranawaka (Dec 22 2019 at 16:44):

Vikramaditya Singh (Dec 22 2019 at 16:45):

Thusal Ranawaka (Dec 22 2019 at 16:47):

[EVERYONE] Learn basic 3D modeling using BRL-CAD type this in the search bar then you will be guided.

Vikramaditya Singh (Dec 22 2019 at 16:49):

Generally asking, how demanding is this competition with respect to time? Also, is this software harder to use than Solidworks or Fusion 360?

Jeffrey Liu (Dec 22 2019 at 17:04):

I don't mean to be rude, but could you guys move the conversation to another channel? @Vikramaditya Singh I will answer your question somewhere else so that it doesn't interfere with the appleseed channel

Zyu (Dec 23 2019 at 20:24):

Sumagna Das (Dec 24 2019 at 06:50):

hey @Sean my appleseed is not building so can i use the example from the installation as a base and write a program fof task #3(i am still working on it)

Sumagna Das (Dec 24 2019 at 06:52):

Sumagna Das (Dec 24 2019 at 07:08):

Sean (Dec 24 2019 at 07:23):

Sean (Dec 28 2019 at 06:48):

Don't know if you're still trying @Sumagna Das but don't recommend building appleseed from source (but do recommend building brl-cad from source).

starseeker (Jan 05 2020 at 15:21):

@Jeffrey Liu I saw you mentioned you sometimes dual-boot to Linux - if you decide to continue with the Appleseed tasks at some point, I'd suggest doing any initial experiments with integrating with BRL-CAD on that platform if you're at all comfortable working there.

I've managed to get a basic "art" executable building there using the binary Appleseed downloadable from their website, as long as you configure BRL-CAD to build with system libpng and libz and have Appleseed where CMake can see it:

If you start from Windows, you'll have to figure out how to mix appleseed with librt on that platform - that's currently completely untried, so I don't know what you'd be up against. Hopefully, on the Linux side, there'd be a much shorter path to start integrating the work you've done with the "art" executable.

starseeker (Jan 05 2020 at 15:22):

(Alternately, if you prefer not to boot to Linux a VirtualBox vm with Ubuntu installed would be another option.)

Jeffrey Liu (Jan 05 2020 at 17:14):

Ah ok, thanks for the heads up! I chose to work on Windows because I was having some issues with BRLCAD on Linux at first (if you remember, MGED wasn't exactly working correctly for me). However, it does seem like CMake in general is easier to manage on Linux, so that'll definitely be something I'll try.

Jeffrey Liu (Jan 05 2020 at 17:17):

By the way, @Sean I looked at the Appleseed integration task #7 requirements, and since "creating the art application" was part of it, if it's already done, then would the only part of the task be to handle the docbook manual stuff?

Jeffrey Liu (Jan 05 2020 at 17:56):

Also, regarding the Linux/Windows situation, I do recall that franz and a couple other developers mentioned the option of perhaps compiling Appleseed with BRLCAD dependencies. This solution would work for both platforms, right?

Jeffrey Liu (Jan 05 2020 at 21:57):

Something else the developers recommended was to build Appleseed with static libraries (although they only mentioned Linux, this should work on Windows as well right?)

starseeker (Jan 06 2020 at 03:39):

@Jeffrey Liu eventually we'll need to build appleseed using the same support libs BRL-CAD itself is using, but (especially doing it cross platform) that's a rather non-trivial task and definitely a non-trivial amount of work.

starseeker (Jan 06 2020 at 03:40):

Static libraries might help, but you'll still have to build appleseed and that in and of itself doesn't look to be trivial (at least, without a very specific compilation environment.)

starseeker (Jan 06 2020 at 03:41):

From a utility standpoint, particularly since you have a demonstrated rendering with librt+appleseed, the biggest bang for the buck would be to get a working "art" application up and running, even if it requires a particular set of configuration options and build setup.

Jeffrey Liu (Jan 06 2020 at 03:42):

Yeah, the integration does seem like quite a challenge. One thing I was wondering, though: say someone were to install BRLCAD as a client - would they be expected to install appleseed as well? Or would it come pre-compiled?

starseeker (Jan 06 2020 at 03:43):

If we can get to a working art application, it's worth doing the necessary deep dive to handle the appleseed building problem.

starseeker (Jan 06 2020 at 03:43):

Jeffrey Liu (Jan 06 2020 at 03:44):

That makes sense, I'm just worried that the approach I end up taking is ultimately not going to work on another platform.

starseeker (Jan 06 2020 at 03:44):

I've got a pending change to how we manage src/other dependency building that should be at least some help as well, but that's waiting on the Git conversion.

starseeker (Jan 06 2020 at 03:45):

The art application will be a C++ application linking to the librt and appleseed libraries. As long as that hook-up is correct on one platform, we can build from there.

Jeffrey Liu (Jan 06 2020 at 03:46):

I think aside from the dependency management, I have a pretty good idea of how the integration might happen, where first the appleseed project would be generated with some converted .g to .obj and then rendered.

starseeker (Jan 06 2020 at 03:48):

<nod> however you want to set it up initially is fine - iterating to the "best" state of the code is a given in this type of work.

starseeker (Jan 06 2020 at 03:49):

the current "art" executable is just doing the hello world example - my initial thought would be to convince it instead to produce the render that you achieved before you switched to EBM.

Jeffrey Liu (Jan 06 2020 at 03:51):

Yeah, I think that would be a good starting point. Something that I'm still not quite sure how to do would be to generate (and then maybe update, if rendering is called multiple times) an appleseed project and then render given a single command.

starseeker (Jan 06 2020 at 03:53):

hmm. Is there something that you need to do that the existing src/rt/art.cpp code isn't doing?

starseeker (Jan 06 2020 at 03:54):

Around line 209 something would change certainly (that's where it's loading the hello world scene.obj file from disk)

starseeker (Jan 06 2020 at 03:55):

Presumably you'd need to insert instead whatever objects you created for the BRL-CAD scene objects.

starseeker (Jan 06 2020 at 03:56):

and I imagine there will be some other tweaks beyond that obvious one, but my hope was that it might be an incremental sort of thing to adjust the helloworld example to do a librt plugin render instead.

Sean (Jan 06 2020 at 03:56):

It's not done -- starseeker did most of the heavy lifting for the build system pieces, linking against appleseed libs, but much more is needed.

Jeffrey Liu (Jan 06 2020 at 03:59):

From what I understand, helloworld.cpp is the code to generate an appleseed project, while something else such a sphereobject.cpp is the code to an actual object that defines intersect() and such. I modified sphereobject.cpp so that the intersect() could work off of librt and a geometry file, but I would still need to generate an appleseed project which implements that plugin to actually render.

Sean (Jan 06 2020 at 04:02):

task #7 is to make a binary application that respects most of rt's options (in the sense that it parses them) and has some initial documentation. it's a task about taking a step on the CAD side (sans appleseed really). task #8 is what is complete now.

Jeffrey Liu (Jan 06 2020 at 04:02):

Although actually, now that I think about it, the plugin I made could just be reused, so it would just be a matter of generating a project that uses the plugin with the correct parameters and then calling appleseed rendering.

starseeker (Jan 06 2020 at 04:05):

@Jeffrey Liu Right. If you need help building the plugin as part of the art build let me know.

starseeker (Jan 06 2020 at 04:06):

although it sounds like there are some tasks ahead of when you'll get to that one...

starseeker (Jan 06 2020 at 04:07):

not to mention finishing up the EBM work - don't let me distract you too much ;-)

Jeffrey Liu (Jan 06 2020 at 04:07):

Sean (Jan 06 2020 at 04:08):

Jeffrey Liu (Jan 06 2020 at 04:09):

Thanks! I think for now, I should be fine just using the dll I built, but going forward, it would be better to include it directly into the source for the user to compile.

starseeker (Jan 06 2020 at 04:10):

@Jeffrey Liu OK. Remember though, I've never tried the current art.cpp build on Windows - I have no idea what will happen.

Jeffrey Liu (Jan 06 2020 at 04:11):

Sean (Jan 06 2020 at 04:14):

Sean (Jan 06 2020 at 04:15):

#9 might be a little tricky, but I hope not if it's easy enough to call into the plugin like the examples

starseeker (Jan 06 2020 at 04:16):

@Sean are we going to have to generate a project and a loadable plugin generally, or will we eventually be able to boil it down to a strictly in-memory process to generate the png file? (I haven't dug deep enough to know...)

Jeffrey Liu (Jan 06 2020 at 04:19):

Actually, I was a little confused by this one. I thought that with the plugin, since it reads .g directly, there wouldn't be a need to load geometry?

starseeker (Jan 06 2020 at 04:23):

@Jeffrey Liu I don't know the details, but I'm presuming that the plugin generates some kind of scene object based on the BRL-CAD geometry information?

Jeffrey Liu (Jan 06 2020 at 04:25):

Well, here's what I initially had: art-plugin.cpp For the most part, it used librt's rt_shootray() to get information directly from the .g but it was still missing a few things, like the UV coordinate at the point of intersection.

starseeker (Jan 06 2020 at 04:25):

My first instinct would be to see if the MeshObject used in the art.cpp helloworld code can be replaced with a ProceduralObject

Jeffrey Liu (Jan 06 2020 at 04:26):

starseeker (Jan 06 2020 at 04:29):

My naive guess is that the key will be in what art.cpp:216 is doing - if we create BrlcadObject objects and insert them, it may even "just work"...

starseeker (Jan 06 2020 at 04:30):

Jeffrey Liu (Jan 06 2020 at 04:30):

That's what I was hoping, and although I was manually editing the project to test the plugin, I can't see why generating it instead wouldn't work.

Jeffrey Liu (Jan 06 2020 at 04:31):

Sean (Jan 07 2020 at 07:15):

Sean (Jan 07 2020 at 07:21):

@Jeffrey Liu it depends how 'art' is set up. conceptually, you were running the plugin within the context of the appleseed renderer that has default notions of a scene, a view, a project, etc.

Sean (Jan 07 2020 at 07:21):

NONE of that exists for 'art' until it is implemented, so the assumption is that there is some basic setup that is going to be required before you'll be able to call the plugin.

Sean (Jan 07 2020 at 07:23):

it may not be necessary, but I don't see how it'll work without first loading the geometry in art, and then passing or calling into that loaded geometry in the plugin. that may be something as simple as changing when the geometry loading function is called, or something else might be needed, because we do obviously only want to load geometry once if we can.

Sean (Jan 07 2020 at 07:26):

or maybe nothing needs to change, but have to keep in mind some of the things rt is doing that will have to be replicated include setting up default view that is based on the geometry. presently, the geometry is loaded and prep'd in rt so it can figure out what size to make the render window, where to create default lights, what rays to shoot, etc.

Jeffrey Liu (Jan 07 2020 at 12:50):

Ah right, I think that makes sense. I forgot to consider that everything is being done from "scratch" rather than from something like appleseed studio.

Sean (Jan 07 2020 at 22:27):

Jeffrey Liu (Jan 08 2020 at 09:53):

Jeffrey Liu (Jan 10 2020 at 02:26):

By the way, I noticed that starseeker created art.cpp inside of src/rt. Is there any advantage to doing it there rather than create a new src/art? Personally, I was thinking of creating a new directory for organizational purposes.

Sean (Jan 10 2020 at 17:11):

new directory is just fine. the advantage of src/rt is so you can reuse and call into the existing source files that rt uses for things like option parsing, but there are other tools that "peek" into the rt directory for those files (like "remrt")

Jeffrey Liu (Jan 10 2020 at 17:47):

Mikki Jhuria (Jan 10 2020 at 18:04):

Hello, Can anyone please tell me how to work on a model and make one I have absolutely no knowledge of how to input the data into MGED.

Jeffrey Liu (Jan 10 2020 at 18:28):

So when you mentioned that the application would need to be able to parse rt's options, would I need to use "remrt" somehow to access those source files that can handle that?

Jeffrey Liu (Jan 10 2020 at 18:39):

Oh also about this path on the task page doc/docbook/man1/art.xml, did you mean doc/docbook/system/man1/art.xml?

starseeker (Jan 11 2020 at 02:24):

starseeker (Jan 11 2020 at 02:28):

So for option parsing there are a few options... I suppose reusing src/rt/opt.c is probably the simplest.

starseeker (Jan 11 2020 at 02:30):

Eventually I'd like to get a bu_opt based parser for those options, but that's probably not a good GCI task.

starseeker (Jan 11 2020 at 02:31):

Definitely not, in fact - there'd be some custom logic needed in all likelihood.

Jeffrey Liu (Jan 11 2020 at 05:40):

So when you say reuse src/rt/opt.c, would that involve somehow accessing that file from src/art, or do you mean to just copy the file into src/art/opt.c as well?

Sean (Jan 11 2020 at 05:41):

Jeffrey Liu (Jan 11 2020 at 05:41):

Sean (Jan 11 2020 at 05:41):

you just reference it in the CMakeLists.txt file if it needs to be linked against, and you just declare the functions and variables you use from it before using them

Jeffrey Liu (Jan 11 2020 at 05:42):

Oh that makes more sense. If I may ask though, what is remrt and how is it used?

Sean (Jan 11 2020 at 05:44):

it lets you run rt across more than one computer so they can all work on the same image

Jeffrey Liu (Jan 11 2020 at 05:45):

Oh that's really cool, I think I've heard about things like that for blender as well - like cloud rendering or something

Sean (Jan 11 2020 at 05:46):

Sean (Jan 11 2020 at 05:47):

at least the first to demonstrate real-time rendering via this distributed computation method

Jeffrey Liu (Jan 11 2020 at 05:49):

Oh wow I didn't know that, that's something I might want to look into later, but I guess I won't be using it for src/art

Sean (Jan 11 2020 at 05:49):

remrt was used back in the early 80's at a time when rendering used to take several minutes for even simple scenes, remrt+rt was use to render animation around 5 frames per second

Sean (Jan 11 2020 at 05:49):

appleseed's rendering method is 100x slower than what rt is doing as it's a much more advanced light simulation

Sean (Jan 11 2020 at 05:50):

bidirectional path tracing is a comparatively expensive method, so it will benefit greatly from more cpu cores

Sean (Jan 11 2020 at 05:51):

but baby steps. first is working at all. then working multithreaded. then we can think about how to handle distributed.

Sean (Jan 11 2020 at 05:51):

CMakeLists.txt:BRLCAD_ADDEXEC(remrt "../rt/opt.c;ihost.c;remrt.c" "liboptical;libfb")

Sean (Jan 11 2020 at 05:51):

Jeffrey Liu (Jan 11 2020 at 05:52):

Yeah, I think I'm thinking a little too ahead right now. For now, task 7 - is that also what you were looking for when you were talking about the option parsing?

Sean (Jan 11 2020 at 05:53):

the general idea is that the tool will greatly benefit if it can be a drop-in replacement for rt

Sean (Jan 11 2020 at 05:54):

that means it needs to handle some of rt's options like -a -e for azimuth and elevation (e.g., rt -a 35 -e 10 ...) or -s for size (e.g., rt -s1024)

Sean (Jan 11 2020 at 05:54):

it's really just a handful, not necessarily all of them, but some of them like -M are rather complicated

Jeffrey Liu (Jan 11 2020 at 05:54):

Ah ok, thanks! I think I need to research/learn a lot more about CMake if I want to do all these things that we've talked about for appleseed - right now all the macros are really confusing so it takes me a while to kinda understand what's actually going on, but I guess some of that also comes with experience

Sean (Jan 11 2020 at 05:55):

we ideally want it to set up essentially the same view, but just render a much more visually interesting image

Sean (Jan 11 2020 at 05:55):

or just do whatever you need to do and one of the other devs can clean it up after you get it working

Sean (Jan 11 2020 at 05:56):

it can quickly turn into a major distraction. it's more important that you demonstrate the capability bits first.

Jeffrey Liu (Jan 11 2020 at 05:57):

Yep, starseeker has already helped me a ton for both ebm and appleseed. I don't want to bother the devs too much though, especially with simple questions that can be googled.

Jeffrey Liu (Jan 11 2020 at 06:03):

I'm still not really sure how to proceed with the Appleseed linkage though - I think the easiest way, manually speaking, would be to just include the appleseed dll built with static libraries, but this probably isn't ideal in the long run?

Sean (Jan 11 2020 at 06:03):

Sean (Jan 11 2020 at 06:04):

Sean (Jan 11 2020 at 06:06):

Jeffrey Liu (Jan 11 2020 at 06:09):

Uh, I'm still on Windows because I was having some trouble with Linux, so I don't think the CMake logic would work.

Sean (Jan 11 2020 at 06:09):

Sean (Jan 11 2020 at 06:10):

it's simply relying on FindPackage(Appleseed) to work, which is to say that it wants you to have installed appleseed first and if it can detect it, variables get set where the libraries were found, and it should work.

Sean (Jan 11 2020 at 06:11):

if anything, there will be variables you can set manually in cmake to make it work. we can walk you through that bit but the first thing is to simply try it and report back.

Jeffrey Liu (Jan 11 2020 at 06:12):

I'm not too sure, but I also did just svn update and then reconfigure cmake yesterday, and it said appleseed wasn't found even though I had it installed.

Sean (Jan 11 2020 at 06:13):

well that's actually good in a way, because you didn't tell it where to find appleseed

Jeffrey Liu (Jan 11 2020 at 06:19):

Oh, is there something that I would need to set somewhere? I thought find_package just found things like that automatically if there existed a CMake text there

Sean (Jan 11 2020 at 06:19):

Two things I would check are 1) what the Cmake build output and error logs say when it tried to find appleseed and 2) what cmake variables there are that can be set (dump the list on the ccmake advanced options listing is one way).

Sean (Jan 11 2020 at 06:21):

find_package finds things automatically that are installed in system locations, which on windows is essentially nothing because most apps don't install into system locations. They go into program files or elsewhere, so you have to tell cmake where to look.

Sean (Jan 11 2020 at 06:21):

Sean (Jan 11 2020 at 06:23):

Jeffrey Liu (Jan 11 2020 at 06:27):

Is this what you were referring to? CMakeOutput.log It looks like the only mention of appleseed is STATUS: Could NOT find APPLESEED (missing: APPLESEED_LIBRARY)

Sean (Jan 11 2020 at 06:28):

Jeffrey Liu (Jan 11 2020 at 06:29):

Sean (Jan 11 2020 at 06:31):

Sean (Jan 11 2020 at 06:35):

Jeffrey Liu (Jan 11 2020 at 06:37):

So that would just be something like set(Appleseed_ROOT "path/to/appleseed") right before the rest of the logic right?

Sean (Jan 11 2020 at 07:02):

Sean (Jan 11 2020 at 07:03):

Mikki Jhuria (Jan 11 2020 at 07:08):

BRL-CAD main repository has between a: 0-7000, b: 7001-70000, or c: 70001-100000 commits can somebody help me with this I can figure it out from BRLs github page...Please

Mikki Jhuria (Jan 11 2020 at 07:24):

Mikki Jhuria (Jan 11 2020 at 07:25):

starseeker (Jan 11 2020 at 13:21):

Note I have no idea how libz and libpng will play out on Windows with the art.cpp build... on Linux I had to use system libs, our bundled ones didn't work. Building with "system libs" on Windows is theoretically possible, but I've never done it personally - no idea if it works.

starseeker (Jan 11 2020 at 13:22):

On linux the CMake line I used (after installing the libpng and libz development packages) was:

cmake .. -DAPPLESEED_ROOT=/path/to/appleseed -DBRLCAD_PNG=SYSTEM -DBRLCAD_ZLIB=SYSTEM

starseeker (Jan 11 2020 at 13:50):

@Jeffrey Liu The art binary is a really mean way to get introduced to our CMake build - it's one of the more challenging scenarios (3rd party binary being linked in on Windows) and it's also an area where there are pending changes to how we're going to manage the process anyway.

Any way you can get art building is fine for these purposes - once it is demonstrated to work, we'll begin the process of setting up Appleseed as a proper src/other BRL-CAD dependency. (That'll be epic, but worth it if we can leverage them for high quality rendering...)

In the longer term, if you really want to do a deep dive in to our CMake, some particulars of our build system are documented in the following report (somewhat dated now, but still should have some useful content):
https://www.arl.army.mil/arlreports/2013/ARL-TR-6475.pdf

For writing CMake, there are a number of resources online - this looks like it might be a decent starting point, although I've not been through it in detail:
https://cliutils.gitlab.io/modern-cmake/

Note that our CMake is a bit conservative by modern standards - there are a number of features we really should be making better use of that I've never had time to retrofit. Also, we are very ambitious in a couple ways which so far as I know are still unique in CMake land - in particular our 3rd part build management, automatic handling of multi-config building, and maintaining a complete list in CMake of all files significant to the build.

We also micromanage our build flags, specifically enabling a wide variety of warnings. We have a DocBook compilation setup used to produce html, man and (optionally) PDF versions of our documentation as part of the build, some custom logic for Tcl/Tk related requirements, and (although we haven't turned it on yet) an option to use astyle to enforce style conventions at build time.

The upshot is our logic won't look very much like "vanilla" CMake, although there are usually analogies - BRLCAD_ADDEXEC, for example, is our wrapper around add_executable and BRLCAD_ADDLIB wraps add_library.

That's why I went ahead and set up src/rt/CMakeLists.txt to build art.cpp - hopefully, that should make it more straightforward to get the basic setup going.

starseeker (Jan 11 2020 at 13:54):

@Jeffrey Liu Tell you what - I'll go ahead and shift the art.cpp file to src/art and get it set up, since I have a machine where I can test it - I almost did that anyway, but got lazy ;-)

starseeker (Jan 11 2020 at 14:29):

@Jeffrey Liu OK, moved - the build part of the opt.c is there as well, but the actual use of it in the logic is still up to you. You'll need to re-run CMake, since the build logic is changed to reflect the moved files.

Mikki Jhuria (Jan 11 2020 at 14:36):

Jeffrey Liu (Jan 11 2020 at 16:37):

Thanks so much for your help @starseeker! Although, in the future, you could just let me know what to do and I could do it myself :) I don't want to just have other devs be doing the work!

Jeffrey Liu (Jan 11 2020 at 16:38):

As for the conflicting dependencies, many of the Appleseed devs have recommended building the appleseed shared library using static libraries. Would that help that issue?

Jeffrey Liu (Jan 11 2020 at 16:43):

Thank you for pointing me to those CMake resources as well by the way, I'll be sure to read through those. I was trying to just use CMake.org but I wasn't getting a good overall grasp.

starseeker (Jan 11 2020 at 16:58):

@Jeffrey Liu In this instance I'm just trying to clear away the underbrush so you can focus your efforts on the core functionality. Like Sean said earlier, build system issues can be quite a distraction. You'll notice I didn't actually hook up any option handling at all in the code ;-)

starseeker (Jan 11 2020 at 16:59):

I'm not 100% sure if the static lib bit would work or not - we'd have to try it and see. You may end up having to do that on Windows - don't know for sure.

starseeker (Jan 11 2020 at 17:07):

Jeffrey Liu (Jan 11 2020 at 17:08):

Still kinda like November, mged was being weird (took a really long time to open)

Jeffrey Liu (Jan 11 2020 at 17:09):

starseeker (Jan 11 2020 at 17:09):

On first run, or on all runs? I've had MGED be slow to load the first timeout of the gate as well...

starseeker (Jan 11 2020 at 17:10):

Another possibility might be to disable OPENGL adn see if the X display manager works better - our use of OpenGL is quite... quirky by modern standards.

Sean (Jan 11 2020 at 17:11):

There is some issue there that I've not been able to figure out. It seems to happen cross-platform to varying degrees where there is a 10-100 second delay the first time it's run. I've not been able to catch it in the act yet to figure out where the time is actually being spent.

Sean (Jan 11 2020 at 17:12):

When it first happened, I attributed it to prebinding, but that doesn't explain it happening on Windows.

starseeker (Jan 11 2020 at 17:13):

Sean (Jan 11 2020 at 17:13):

Jeffrey Liu (Jan 11 2020 at 17:13):

This was happening on Debian - if I recall correctly, doing mged -c and choosing the X display manager did help a little

Sean (Jan 11 2020 at 17:14):

Jeffrey Liu (Jan 11 2020 at 17:15):

That and the fact that I'm just a little more comfortable with MSVS is why I chose to stay on Windows, so hopefully I can still work out the appleseed dependency stuff

starseeker (Jan 11 2020 at 17:15):

@Jeffrey Liu If it happens two times in succession it might be worth slapping a profiler like perf on it to see if we can figure out what's going on for sure. (At some point down the road - by all means if you're more comfortable with MSVC stay there for now.)

Sean (Jan 11 2020 at 17:16):

compiling everything static should avoid a host of issues, but I wouldn't try that until you run into a problem.

Sean (Jan 11 2020 at 17:17):

static libs are going to mean the linker does't have to resolve symbols when the appleseed libs are loaded. if the appleseed libs themselves are static, there shouldn't be any conflict with our versions.

Sean (Jan 11 2020 at 17:18):

starseeker (Jan 11 2020 at 17:18):

Unless the Appleseed project has a static download available that would mean an all-up build of Appleseed's sources (and possibly dependencies)...

starseeker (Jan 11 2020 at 17:18):

Which might actually be easier on Windows, in some ways, if it does come to that

Sean (Jan 11 2020 at 17:20):

@starseeker FYI, I think we should rename our libz and libpng libraries. I believe both libraries have a prefix option we can specify when we build them. If we do that, it should avoid this issue, fix the issue on mac, fix the issue we've had with things like freetype, etc.

Jeffrey Liu (Jan 11 2020 at 17:20):

Well the big folder of windows deps that Appleseed provides also has the static option, so it may be an option

Sean (Jan 11 2020 at 17:21):

I was noticing that, why I mention it. I think static is necessary for some of appleseeds bigger commercial customers like Maya

starseeker (Jan 11 2020 at 17:22):

Ah, that's good news. @Jeffrey Liu Here's your chance to tangle with CMake after all then, if you're so inclined - you'll need to point the art build logic (either the FindApplseed.cmake search or hard-coding in the src/art/CMakeLists.txt file) to those versions and figure out how to get them linked in.

starseeker (Jan 11 2020 at 17:23):

@Sean That'll complicate switching between SYSTEM and BUNDLED versions... or where you thinking to have our own logic always use the prefixed versions and never rely on the system?

starseeker (Jan 11 2020 at 17:24):

@Jeffrey Liu I'm not actually sure how to build with MSVC using static 3rd party libs, so I'm afraid I can't be too much help for this part - Sean probably knows more than I do though...

Sean (Jan 11 2020 at 17:29):

@starseeker from my understanding, the way their prefixing system works, we'd add a define during compilation (or not) depending on whether we're using ours (or system). that toggles the magic in headers so the right symbols are declared/used, and then the resulting binary only works with one or the other, not both. doesn't require code to change.

Jeffrey Liu (Jan 12 2020 at 17:29):

Hey, I was working on task 7 (for now, I'm just trying to get some other stuff besides the appleseed libraries themselves figured out), and I realized that for rt, there is a main.c which calls usage(), which then calls default_options() that sets most of the options. Would this also be recommended for art?

Jeffrey Liu (Jan 12 2020 at 17:51):

Also, there is do.c, which is where the rt_cmdtab[] is declared for opt.c. I haven't looked through all of it yet, but would it be safe to just include it in the executable, or are there functions that are specific to rt/rtuif?

starseeker (Jan 12 2020 at 20:03):

For art, we want to do (for the moment) what remrt did and just declare a null command table. (If I remember correctly I tossed such a table into art.cpp during build testing.)

The table as implemented by rt ropes in a lot of other rt functions, and it's not clear how many of those are going to translate. I think we'll eventually want some of them, but a lot will depend on the details of what's needed to get appleseed running.

starseeker (Jan 12 2020 at 20:04):

I believe calling usage() and having the default_options() set is the correct initial approach.

starseeker (Jan 12 2020 at 20:11):

the "rt_do_cmd" function lives down in librt, and we should probably either move a lot of the "standard" commands down there as well or split that whole command API off into it's own module in some shape or form. Sean may have more specific ideas about what to do refactoring wise...

Jeffrey Liu (Jan 12 2020 at 20:16):

Ah ok, thanks for the clarification! I found the null command table, but I was asking because I was still getting an error upon compilation (something like extern command_table rt_cmdtab[] unresolved). Could it still be happening because they're in different directories?

starseeker (Jan 12 2020 at 20:17):

starseeker (Jan 12 2020 at 20:19):

Oh... you might need to try encapsulating the rt_cmdtab struct definition in "extern "C" {" since art is a C++ file.

starseeker (Jan 12 2020 at 20:20):

starseeker (Jan 12 2020 at 20:21):

GCC/clang seem to be somewhat more forgiving, on average - usually it's forgetting to export/import something correctly, but MSVC will somtimes complain about different aspects of the C++ code too.

starseeker (Jan 12 2020 at 20:22):

@Jeffrey Liu If you want to try an experiment, you might rename main.c to main.cpp in the main rt application and see what blows up...

starseeker (Jan 12 2020 at 20:24):

We mix C and C++ code in a number of places (brep.h is especially bad in that regard, IIRC) and there are various gotchas that need to be observed when doing so. I usually learn about them the way bugs learn about windshields.

Jeffrey Liu (Jan 12 2020 at 20:26):

Haha sure I'll try that - although wouldn't it be easier to do the "extern 'C" {" stuff in art.cpp?

starseeker (Jan 12 2020 at 20:31):

Yeah, that's what I meant - the rt_cmdtab definition in art.cpp may need to be wrapped

Jeffrey Liu (Jan 12 2020 at 20:33):

Oh sorry, I think I misunderstood, I thought you were suggesting main.c to main.cpp as a fix to the previous problem rather than an experiment. I might try it anyways just to see how it goes though :)

starseeker (Jan 12 2020 at 20:34):

Ah. No, my apologies. I was suggesting the main.cpp thing as a way to do an independent experiment of how the rt logic will behave when C++ is tossed into the mix.

starseeker (Jan 12 2020 at 20:34):

Since rt itself already builds and works, just changing the one file from C to C++ is one way to find out what the issues involved in such a switch are.

Jeffrey Liu (Jan 12 2020 at 20:38):

Ah ok that makes sense. Thank you for the insight! I haven't really worked with mixing C and C++, so I didn't even know what extern "C" meant before.

starseeker (Jan 12 2020 at 20:40):

Jeffrey Liu (Jan 12 2020 at 20:51):

So back to the part about do.c and such, would you recommend creating some other files (mimicking do.c, having a main.c to initialize things, etc)?

starseeker (Jan 12 2020 at 20:56):

Not unless you have to - I'd just try to get usage to print the help, to start with.

starseeker (Jan 12 2020 at 20:56):

Jeffrey Liu (Jan 12 2020 at 20:59):

I think the main point of the task is just to introduce option parsing (so yeah, probably demonstrating that the options work), and also introducing some initial documentation.

starseeker (Jan 12 2020 at 21:01):

Actually, to demonstrate that options parsing works all you would need to do is print out the values assigned to the various options.

starseeker (Jan 12 2020 at 21:02):

Check with Sean, but usually GCI task scoping isn't too extreme - I'd say try to get the option parser reading in options, and then just print to stdout what option values are should do for a start.

starseeker (Jan 12 2020 at 21:02):

Jeffrey Liu (Jan 12 2020 at 21:04):

Yeah that makes sense - to demonstrate it, I was hoping to get art -h working so that it could print the other defaults along with it. Is that along the lines of what you meant?

starseeker (Jan 12 2020 at 21:22):

Jeffrey Liu (Jan 12 2020 at 23:12):

Alright, I got it to work by calling get_args() and usage() through art. Thanks so much for your help!

Jeffrey Liu (Jan 12 2020 at 23:12):

The next part will be tricky though, since that's when I actually need to worry about the appleseed libraries and such.

Jeffrey Liu (Jan 14 2020 at 06:44):

@Sean for task #8, could I try to compile BRLCAD using appleseed's versions of libpng and zlib (that would solve the conflicting dependencies, right)? Unless there's another method you'd like for me to try first?

Sean (Jan 14 2020 at 07:41):

Jeffrey Liu (Jan 14 2020 at 07:43):

get_filename_component(APPLESEED_LIB_DIR "${APPLESEED_LIBRARY}" DIRECTORY)
file(GLOB APPLESEED_BOOST_SYSTEM_LIB "${APPLESEED_LIB_DIR}/libboost_system-*")
file(GLOB APPLESEED_OPENIMAGEIO_LIB "${APPLESEED_LIB_DIR}/libOpenImageIO.*")

and I checked out the install appleseed/lib directory but the only libs there were appleseed.lib and appleseed.shared.lib - I guess that means our installs on Windows/Linux were slightly different? I was thinking about using find_package(Boost) and find_package(OpenImageIO) instead but I'm not exactly sure how the FindBoost.cmake and FindOpenImageIO.cmake work exactly.

Jeffrey Liu (Jan 14 2020 at 07:47):

Hopefully once I get Boost and OpenImageIO linked in, then compiling BRLCAD using appleseed's versions of libpng and zlib will work :)

Jeffrey Liu (Jan 14 2020 at 08:01):

So yeah, just using find_package() on its own isn't working (even though I've located FindBoost.cmake and FindOpenImageIO.cmake in two different directories), so I'm wondering how I'd be able to locate the two. I do think that the original logic is better though, so I'm gonna try to figure what the issue there was.

starseeker (Jan 14 2020 at 12:41):

@Jeffrey Liu You're into parts where I don' t know the answers now ;-). On Linux I needed the boost and openimageio libs explicitly listed, but it may very well be that Windows won't even need that.

starseeker (Jan 14 2020 at 12:44):

The boost and imageio thing was basically a quick and dirty hack to get it building - a "correct" solution is going to involve properly src/other managing both of those setups (Boost in particular is going to be fun... we tried that once years ago.)

I'd try just not listing them at all and see if pointing to just Appleseed works on Windows.

starseeker (Jan 14 2020 at 12:44):

If not, the next step is to just manually force the necessary variables to specific paths.

starseeker (Jan 14 2020 at 12:45):

starseeker (Jan 14 2020 at 12:48):

Since I've not built against 3rd party Windows libs much, I don't really know how find_package works with .dll vs .lib files and keeping track of all that...

starseeker (Jan 14 2020 at 12:48):

starseeker (Jan 14 2020 at 12:49):

The other thing I can suggest if you're having more trouble is to make a small stand-alone CMake project and just experiment with that (to avoid needing to re-run BRL-CAD's who configure cycle each time you make a change.

Jeffrey Liu (Jan 14 2020 at 16:27):

Ah ok, thanks for the advice! I've been trying to configure my own smaller CMake projects to see how linking goes. I think it is necessary to list them because I was getting a Boost linkage error during compilation, so I guess I'll try forcing the variables for now.

Sean (Jan 14 2020 at 16:29):

@Jeffrey Liu you're also perfectly welcome to edit the generated MSVC files directly to add/list the necessary libraries if you're familiar with how to do it. That may be your fastest path forward if you hit a snag with cmake detection. Totally hacked is quite alright.

Jeffrey Liu (Jan 14 2020 at 17:20):

Ah ok, thank you for the advice! I wasn't sure if I could do that because task 8 seems to want it done through CMake. That said, I got find_package() to work for Boost after setting -DBoost_ROOT through my smaller tests, so I'll try to see if it works on CMake as well.

Sean (Jan 14 2020 at 17:33):

@Jeffrey Liu at this level, all tasks are subject to negotiation and discussion ;) task 8 was primarily completed by starseeker, so the objective is more learning/exploration for you to try and get it working. the more you do, the easier it will be for you and us down the road, but the priority is very much on tasks 9+....

Jeffrey Liu (Jan 14 2020 at 22:59):

Hm yeah that does make sense, I guess I shouldn't get too distracted with the configuration details for now.

Jeffrey Liu (Jan 15 2020 at 01:24):

YIkes, I'm running into quite a difficult dilemma... so basically, when I try to link "common.h" with boost and appleseed, I'm getting this compilation issue Output-Build.txt which is being caused by these lines:

APPLESEED_DLLSYMBOL void sleep(const std::uint32_t ms);
APPLESEED_DLLSYMBOL void sleep(const std::uint32_t ms, IAbortSwitch& abort_switch);

where the macro APPLESEED_DLLSYMBOL is defined as __declspec(dllimport). The issue is that config_win.h also has this macro:

#define sleep(_SECONDS) (Sleep(1000 * (_SECONDS)))

so there's an error because the compiler thinks that I'm trying to redefine a function that's expecting a definition from a dll.

Jeffrey Liu (Jan 15 2020 at 01:28):

I temporarily renamed the config_win.h macro to sleep2, and then everything worked fine. However, that's obviously not going to fly as an actual solution, but I don't think I can just easily rename the appleseed function either. To be honest, I have no idea how to deal with this. Could I get some help in regards to how I could make a compromise between the two?

Jeffrey Liu (Jan 15 2020 at 01:35):

But aside from that (after I temporarily renamed the macro to sleep2), I think I finally got art.exe running the helloworld example on Windows :) test.png

starseeker (Jan 15 2020 at 04:06):

starseeker (Jan 15 2020 at 04:08):

starseeker (Jan 15 2020 at 04:18):

@Jeffrey Liu Don't let the sleep bit worry you too much if you have a workaround - I'd definitely try to get your BRL-CAD rendering to generate from that setup now :-)

Sean (Jan 15 2020 at 06:02):

@Jeffrey Liu if you make sure common.h is first, just add "#undef sleep" before your #include's for appleseed.

Sean (Jan 15 2020 at 06:03):

Jeffrey Liu (Jan 15 2020 at 06:03):

Sean (Jan 15 2020 at 06:04):

doesn't look like brl-cad geometry if I had to guess -- is it manually created in art ?

Jeffrey Liu (Jan 15 2020 at 06:04):

So since art.cpp is just the helloworld example at the moment, it's using the scene.obj provided from the appleseed source.

Jeffrey Liu (Jan 15 2020 at 06:06):

Sean (Jan 15 2020 at 06:08):

Jeffrey Liu (Jan 16 2020 at 18:44):

This might be thinking a little too far ahead (and also just pure speculation), but for appleseed option parsing, I was wondering if it could just work if, for example, after processing options (like -w), I just referenced those variables from opt.c. So like if -w was set, I would just reuse width when creating the appleseed project and calling .insert("resolution", "640 480"). Would there be an issue with that?

Jeffrey Liu (Jan 16 2020 at 18:45):

Also, in the future, if there are any default command line options that only apply to rt but not art, would it help to define some APPLESEED macro and then checking whether it's defined or not when the defaults are set in usage.cpp?

Jeffrey Liu (Jan 16 2020 at 23:37):

Oh also @Sean , I was taking a look at the appleseed command-line version and I saw that task 10 was about "loading brlcad geometry", but I was wondering if it would be possible to just set up rt (configuring ap and rtip correctly), and then raytrace using rt to detect brlcad geometry? My assumption is that with rt set up correctly, then brlcad raytracing will get all of the raytracing information necessary (intersect, etc), and then just pass it down to appleseed for the shading calculations.

Jeffrey Liu (Jan 16 2020 at 23:38):

Kind of like originally with the plugin, where all of the raytracing was getting done through rt. The only difference being that in this case, art would also be the one building the appleseed scene.

Jeffrey Liu (Jan 17 2020 at 04:30):

Ok, so I tried to follow through on what I was trying to say, and I think I got it working up to the point where the project is generating successfully. Rendering still isn't working though, and I think it has to do with the same multi-threading issue as before.

Jeffrey Liu (Jan 17 2020 at 06:18):

So after a lot of manual set up (configuring library directories, etc), one run of art.exe has finally produced an image: test.png

Jeffrey Liu (Jan 17 2020 at 06:18):

Jeffrey Liu (Jan 17 2020 at 06:19):

I think if I can set up the camera settings and such to respect rt, then it'll start looking even more "correct"

starseeker (Jan 17 2020 at 12:33):

Sean (Jan 17 2020 at 14:04):

@Jeffrey Liu that's like the best teaser you could have accidentally stumbled across

Sean (Jan 17 2020 at 14:07):

Honestly, that's probably what I'd think to do too. Don't know if it's an issue. Really most of the option parsing can just be thought of as simply setting some global variable so you can get at the value later, even for things like -a -e or -A or -C etc

Sean (Jan 17 2020 at 14:08):

The goal is going to be compatibility with what the user is seeing in MGED, so it's likely going to end up being very similar to what RT does, which is why the other task just suggested calling into rt's opt.c so it's global vars are set and accessible.

Sean (Jan 17 2020 at 14:25):

I don't think it's necessary. Unsupported options can be disabled (see src/rt/viewcheck.c:application_init() for an example). If it diverges really far (it shouldn't, that's part of the point), then we can refactor/change the default options, move some to a general set that all use, others that are rt-specific to a different set, etc. Don't want to compile-time conditionalize if we can because that's harder to maintain and debug.

Sean (Jan 17 2020 at 14:27):

shading calculations often involves shooting more rays (down in the shading calculations), so the plugin still comes into play. But sure, it's entirely possible to either let appleseed set up the primary rays, or you set up the primary rays and let appleseed handle the secondary. both should be doable.

Sean (Jan 17 2020 at 14:28):

@Jeffrey Liu do you know if appleseed has support for orthographic views or just perspective views?

Sean (Jan 17 2020 at 14:29):

if it doesn't, that'd be a good reason for making art shoot the main rays and only letting appleseed handle secondary rays.

Sean (Jan 17 2020 at 14:30):

would just need to check if there's any other magic going on like image post-processing for depth of field or other effects that can happen after primary rays are fired.

Jeffrey Liu (Jan 17 2020 at 15:07):

I'm not sure yet, but I would assume that it does - I'll try to look around or ask franz for more info about that. Could I ask what you mean by letting art handle the primary rays with appleseed handling the secondary rays?

Jeffrey Liu (Jan 17 2020 at 15:08):

I know that the plugin has 2 different intersect() functions, one for a detailed result with another for just a hit/miss, but I'm not sure how I'd be able to separate that so art could handle it.

Sean (Jan 17 2020 at 16:19):

@Jeffrey Liu in ray tracing, the very first rays that get shot from the camera are called "primary rays". these rays are the primary basis for the image that is generated.

Sean (Jan 17 2020 at 16:21):

those primary rays hit objects in the scene and cause other rays to be fired, for example to see how much light , or the ray is reflected, refracted, scattered, etc. Those are called "secondary rays".

Sean (Jan 17 2020 at 16:23):

The handling of both primary and secondary rays are typically quite different in most rendering systems, even though both involve the same intersection testing (e.g., rt_shootray()).

Sean (Jan 17 2020 at 16:23):

Sean (Jan 17 2020 at 16:26):

Jeffrey Liu (Jan 17 2020 at 23:34):

Ah, I think that makes sense - so I guess there are multiple secondary rays shot for each primary ray hit?

Jeffrey Liu (Jan 17 2020 at 23:37):

Yep, franz responded and he told me that it's just a matter of configuring a pinhole vs orthographic camera. I hadn't found the cornell box example yet though, so thank you for that :)

Jeffrey Liu (Jan 18 2020 at 00:22):

Oh by the way, what did you mean about double prepping the geometry in art and then in the plugin? I thought that it was only being prepped in the plugin (the only argument passed to it is the name of the database), so am I neglecting to account for something?

Jeffrey Liu (Jan 18 2020 at 06:54):

Hm, does opt.c not actually store the .g file name? I'm trying to use it in art.cpp to pass as a parameter, but it looks like opt.c just uses the bu_optarg to store it temporarily.

Jeffrey Liu (Jan 18 2020 at 07:07):

Oh I think I kinda know what you meant by prepping in both art and the plugin... because the rt camera and stuff is set up during rt prep, but I will need those configurations for art, and the issue is rt prep is currently happening in the plugin?

Jeffrey Liu (Jan 19 2020 at 03:26):

Hm, ok I think I got the title file working, but the objects themselves will probably be the larger challenge. I don't think I can just pass the array pointer because franz said passing pointers is quite unsafe... it's probably easier to just concatenate the object names together with spaces in between and then parse again in the plugin, but I'm wondering if there's any better way to get the arguments.

Jeffrey Liu (Jan 19 2020 at 07:59):

Yep, so passing the arguments works. Here's the rendered image when I call art -o havoc.png havoc.g s.tail40 s.tail41 s.tail42: havoc.png It's not the best way for sure, but once I can get passing pointers and stuff figured out, I think a lot of things would get easier/smoother.

Jeffrey Liu (Jan 19 2020 at 08:03):

Or actually, I just realized - if I can pass ap and rtip directly into the BrlcadObjectFactory create() function, things might get a whole lot simpler. I'll have to ask franz more about it though.

Jeffrey Liu (Jan 19 2020 at 16:19):

Update to that: franz said that it should be possible, so I'll have to refactor a lot of my code for the next task. One thing I am curious about, though, is how I'll be able to access the camera settings. It would be great if it was just something I could access through rtip or something, but I'll have to look more into it.

Jeffrey Liu (Jan 20 2020 at 01:48):

Okay, so I was able to refactor so that now the plugin only takes in a pointer for the application and a pointer for the resources. It's still a little messy of course, but it's made some other things (namely the object array) a lot simpler. Next step is probably to configure the camera and such, but I'm having some trouble figuring out how I might be able to access stuff like the rt camera settings.

Jeffrey Liu (Jan 20 2020 at 01:53):

Passing the things as pointers has its benefits and drawbacks, though: since it no longer needs the BrlcadObjectFactory anymore, there should technically be some way to integrate the plugin into the executable without needing an external shared library. However, this also means that if the *.appleseed project was ever going to be created for debugging purposes, appleseed applications would not be able to directly render it.

Jeffrey Liu (Jan 20 2020 at 02:05):

OVERLAP1: /s.tail41
OVERLAP2: /s.tail42
OVERLAPa: dist=(0, 915.813) isol=s.tail41 osol=s.tail41
OVERLAPb: depth 915.81326mm at (4385.66, 236.886, 1083.62) x0 y0 lvl0
(overlaps omitted)

but I'm not really sure how to interpret them exactly. Are they warnings/issues? They don't appear when I render the same objects with rt, which is why I'm asking.

Jeffrey Liu (Jan 20 2020 at 02:15):

Correction: rt produced similar messages, I just looked over them by accident. I guess that's normal then?

Jeffrey Liu (Jan 20 2020 at 05:22):

Ok yeah, so now I think the biggest priorities are to get the appleseed camera set up so that it matches the rt camera. Still can't figure out how to access those rt camera settings though.

Jeffrey Liu (Jan 20 2020 at 07:02):

Hey @Sean, sorry to bother you, but for the "more work needed" part, were you referring to just the struct internal part, or did you want me to include that seperate function as well?

Sean (Jan 20 2020 at 07:05):

The rtip is independent of any camera settings. You can, however, stash any arbitrary user pointers in a variety of BRL-CAD structures including the application struct.

Sean (Jan 20 2020 at 07:08):

They are warnings from within LIBRT that a solidity error was detected during ray tracing. You can ignore them for now. There's a way to turn them off, it's rt's -R option.

Sean (Jan 20 2020 at 07:09):

Rt's view settings are in a few variables. The easiest to start with will likely be the -a -e options, following the processing they do and trying to mimic that as that's the base use case.

Sean (Jan 20 2020 at 07:12):

Not at all a bother, just catching up in order to minimize missing important things. The vls one is wrong (happens to work they way you're using it now, but you got lucky ;)), but it's trivial to fix. The separate function is probably the easiest and least amount of code change. Adding another constructor should also work, but then you'll either want to make a function they both call or you'll have some duplication.

Jeffrey Liu (Jan 20 2020 at 07:13):

I think my main issue right now would be getting the default camera location. I'm pretty sure I'd need the appleseed and the default rt camera settings to match so that appleseed knows where to look, but it seems to vary based on the size of the objects and such so I'm not sure how rt handles it exactly.

Sean (Jan 20 2020 at 07:13):

@Jeffrey Liu so they only thing I want to make sure is that you get to claim your last task(s) in time before the deadline, particularly if you have any other tasks pending.

Sean (Jan 20 2020 at 07:15):

You're right, the default render views are based on the approximate size of geometry which is calculated during your rt_prep_parallel() call.

Sean (Jan 20 2020 at 07:17):

so you're going to have to calculate the view similarly to how rt's doing it, and then translate to appleseed inputs.

Jeffrey Liu (Jan 20 2020 at 07:17):

Thank you, I really want to finish up to task 12 if that's possible :) For now, could I submit the task with the bu_vls fix, and then try to add the separate function for task 11?

Sean (Jan 20 2020 at 07:17):

you'll want to look at do_frame() in src/rt/do.c, particularly at/after the do_prep() call in there.

Sean (Jan 20 2020 at 07:19):

you'll see do_frame() calls grid_setup() ... that's the main workhorse and it's over in worker.c

Sean (Jan 20 2020 at 07:20):

you can probably call grid_setup() directly after prep, but it reads a number of global variables that you'll have to make sure have been initialized properly after option parsing (e.g., the globals that -a and -e set).

Sean (Jan 20 2020 at 07:22):

in fact, most of the functions even for option parsing, you should be able to call directly

Jeffrey Liu (Jan 20 2020 at 07:23):

I'm still not too sure about the separate function part though - I am passing the database path and object names as part of the ParamArray, but I'd probably have to deal with the whole argument handling thing all over again. I think the main issue is that I can't just pass an array as an input parameter, so something with a space in the name would be especially difficult to deal with.

Sean (Jan 20 2020 at 07:23):

passing -a and -e ends up calling do.c's do_ae() function which ends up using the prepped rtip to set eye_model, which grid_setup() ends up using in its calculations.

Sean (Jan 20 2020 at 07:27):

I'm not sure I follow the implication. The ParamArray seems fine. You pass it an array of names, which is ideal/fine.

Sean (Jan 20 2020 at 07:27):

Jeffrey Liu (Jan 20 2020 at 07:28):

The issue with ParamArray, I think, is that it's part of appleseeds input handling (it's not actually just an array), so there's the issue of handling an unknown number of objects

Sean (Jan 20 2020 at 07:28):

spaces was just an example. could have quotes or backslashes or special characters... some of those characters have special meaning. You'd have to encode and decode, which is really ugly (and seems completely unnecessary as you were successful).

Sean (Jan 20 2020 at 07:29):

Jeffrey Liu (Jan 20 2020 at 07:31):

So for each parameter in ParamArray, there is a separate function to be called to get the required or optional parameter. When appleseed is writing the project file, it will convert the data type to a string, so for something like an array, which is basically the pointer to the first element, something other than the list of objects might get written to the project file.

Sean (Jan 20 2020 at 07:31):

The issue, I thought, was that you extended BrlcadObject::BrlcadObject() with two additional parameters, with an ap and resources

Sean (Jan 20 2020 at 07:32):

Jeffrey Liu (Jan 20 2020 at 07:33):

"object_names" is my creation, if you look at brlcadplugin you'll see that there's a function named get_objects, which gets a string of the concatenated objects at the moment.

Sean (Jan 20 2020 at 07:34):

Jeffrey Liu (Jan 20 2020 at 07:36):

I think I'm not actually using the MeshObjectsArray anymore, it's just the singular BrlcadObject (which uses the prepped rtip) that's being inserted into the assembly. That's also the ParamArray I'm referring to, which has a database_path and object_names.

Jeffrey Liu (Jan 20 2020 at 07:37):

So basically, the only way for me to communicate with BrlcadObject is either through the constructor or through the ParamArray, which looks like this right now:

asf::auto_release_ptr<renderer::Object> brlcad_object(
    new BrlcadObject{"brlcad geometry",
             asr::ParamArray()
             .insert("database_path", file)
             .insert("object_names", objects),
             ap, resources});
    assembly->objects().insert(brlcad_object);

Jeffrey Liu (Jan 20 2020 at 07:39):

If I wanted to pass an array (to later be recorded in the project file), it woud need to be through the ParamArray() where I insert the two required parameters. However, the issue with passing an array, as I mentioned before, is that appleseed would convert it weirdly (I actually tried passing the struct application pointer as a ParamArray parameter at first, but I was getting an error because of the way they were converting the parameters to strings).

Sean (Jan 20 2020 at 07:40):

Okay, I see you're not using get_objects() now (and it's not an Object:: method in appleseed)

Sean (Jan 20 2020 at 07:40):

Sean (Jan 20 2020 at 07:41):

so I would suggest just keeping it simple and slowish for now -- let the plugin just have the list of objects from object_names and let it prep them as it was doing

Sean (Jan 20 2020 at 07:41):

Sean (Jan 20 2020 at 07:42):

Jeffrey Liu (Jan 20 2020 at 07:43):

So with that way, it'll probably still have the issue with the spaces because of the weird parsing which separates by space. To be honest, I think how it's being handled right now is fine, seeing as the .appleseed writing is more of a side debugging thing.

Sean (Jan 20 2020 at 07:43):

the problem is only when run from within appleseed which is to say that you still need an api-compatible Object constructor that it can call into

Sean (Jan 20 2020 at 07:43):

Sean (Jan 20 2020 at 07:45):

and if you call into that constructor, you simply initialize an ap and resources based on object_names and database_path, and call the other constructor (or a common function they both call)

Sean (Jan 20 2020 at 07:45):

Jeffrey Liu (Jan 20 2020 at 07:46):

Sean (Jan 20 2020 at 07:46):

so you'll just need to add another constructor, one that conforms to
Object(
const char* name,
const ParamArray& params);

Sean (Jan 20 2020 at 07:47):

and to make that work, you'll obviously need TO CREATE an ap (shouldn't need resources, they are stashed in the ap) in that constructor (or in a function that constructor calls)

Sean (Jan 20 2020 at 07:48):

Jeffrey Liu (Jan 20 2020 at 07:50):

Ok yeah, that seems solid. I normally wouldn't ask of this, but since GCi is approaching its end and task 11 is basically still about rendering geometry, could I submit the bu_vls fix for task 10 and then do this constructor stuff for task 11?

Sean (Jan 20 2020 at 07:51):

Jeffrey Liu (Jan 20 2020 at 07:51):

Alright thanks so much! I really want to try my hand at task 12 before the task claim deadline.

Sean (Jan 20 2020 at 07:52):

I'd also like to work on getting your patches integrated formally now that things are starting to slow down enough

Sean (Jan 20 2020 at 07:52):

Jeffrey Liu (Jan 20 2020 at 07:54):

Colors would be awesome, although I think I'd have to figure out how to position the lights properly and stuff. Right now the geometry is just being lit by the skylight.

Sean (Jan 20 2020 at 07:54):

Sean (Jan 20 2020 at 07:55):

Sean (Jan 20 2020 at 07:56):

still camera is far more important first, that's why I said hope you keep this up. ;)

Jeffrey Liu (Jan 20 2020 at 07:57):

Sean (Jan 20 2020 at 07:57):

there are literally thousands of people that will end up using this when/if it's ever completed. that's why this has been a priority for a while now.

Sean (Jan 20 2020 at 07:57):

Jeffrey Liu (Jan 20 2020 at 07:58):

I'm hoping that colors are pretty easy to extend - how does rt handle it? It might be a bit more of a challenge if the colors are determined at the time of ray intersection.

Jeffrey Liu (Jan 20 2020 at 07:59):

I would definitely love to see this to competion. Implementing it into the build system seems like a whole other monster though.

Sean (Jan 20 2020 at 08:00):

colors are a property of the geometry. it's handled in a manner quite similar to appleseed. rt looks at an object's color value and the set shader to figure out what to do next (i.e., how to shade that particular hit point).

Jeffrey Liu (Jan 20 2020 at 08:02):

Oh right, right now the project is using the solid color material, which is why I kinda confused myself.

Sean (Jan 20 2020 at 08:04):

the final "color" is calculated after ray intersection for both rt and appleseed. rt uses a classic local illumination method where the color is based heavily on the color of the object, the surface normal, whether the light is visible from that point, and a few other things. appleseed uses a classic global illumination model where the color is also based heavily no the color of the object, but it performs a rather different light simulation which is what makes it more realistic looking even with default settings.

Sean (Jan 20 2020 at 08:04):

Sean (Jan 20 2020 at 08:05):

Jeffrey Liu (Jan 20 2020 at 08:05):

Yeah I was about to say that it was getting quite late. Thanks so much for your help!

Jeffrey Liu (Jan 20 2020 at 08:05):

Jeffrey Liu (Jan 21 2020 at 06:54):

Hey @Sean, I just saw your comment on the task. I could do that, but the real issue is how these object names get recorded in the appleseed project. The BrlcadObject (as I've defined it) requires 3 parameters: a database_path, an object_count, and object_names. The function build_project() passes down the parameters for the database_path and the string for object_names, while object_count found from objc. As I've mentioned before, I can't just pass an array to object_names because it either wouldn't work, or the pointer to the first element would be written to the project file.

Sean (Jan 21 2020 at 06:54):

Sean (Jan 21 2020 at 06:55):

Jeffrey Liu (Jan 21 2020 at 06:56):

I'm first concatenating the object names together with bu_vls_from_args before passing it, and then I'm doing a pretty weird method to ultimately get a (const char**) objv:

char* objv = (char*)bu_calloc(objects.size() + 1, sizeof(char), "obj array parameter");
    strcpy(objv, objects.c_str());

    configure_raytrace_application(dbname.c_str(), objc, objv);

Jeffrey Liu (Jan 21 2020 at 06:57):

/* parse object arguments */
    char** objv = (char**)bu_calloc(objc + 1, sizeof(char*), "obj array");
    char* token = strtok(objects, " ");
    int idx = 0;
    while (token != NULL)
    {
    objv[idx++] = token;
    token = strtok(NULL, " ");
    }

    /* include objects from database */
    if (rt_gettrees(rtip, objc, (const char**)objv, npsw) < 0)
    {
    fprintf(output, "Loading the geometry for [%s] FAILED\n", objects);
    fflush(output);
    }

Jeffrey Liu (Jan 21 2020 at 06:59):

I have thought about adding more parameters so that each parameter (maybe like "object1_name" or something) could hold a separate object name, but from what I know, this wouldn't really work out if there's an indefinite number of object arguments.

Sean (Jan 21 2020 at 07:02):

Jeffrey Liu (Jan 21 2020 at 07:02):

Here's the command itself, which gets the required parameter "object_names" from the ParamArray:

std::string
BrlcadObject::get_objects() const
{
    return m_params.get_required<std::string>("object_names");
}

Sean (Jan 21 2020 at 07:03):

Sean (Jan 21 2020 at 07:04):

Sean (Jan 21 2020 at 07:05):

ParamArray looks to be templatized, so it theoretically could contain any object type

Jeffrey Liu (Jan 21 2020 at 07:05):

I think I was actually using BrlcadObject the whole time, I just had that part commented out so it might've looked like I was using the MeshObjectArray (sorry about that, I probably should've removed it)

Jeffrey Liu (Jan 21 2020 at 07:07):

ParamArray is able to contain any object type, but the problem arises when the .appleseed project file actually records the parameters - the parameter would need to be able to be converted to a string, and it would also need to be something readable after being written

Sean (Jan 21 2020 at 07:11):

sure, but that looks like it's something that'd be already handled internally. I'm seeing linkages in ParamArray where it's simply a string Key to a Dictionary value. Those interfaces, at least I would assume, would be where I'd expect serialization/deserialization to be handled consistently.

Sean (Jan 21 2020 at 07:11):

Jeffrey Liu (Jan 21 2020 at 07:21):

Hm, I haven't really thought to look at any of the builtin appleseed containers, which is probably one of the first things I should've done... I'll take a look at it - I've also asked franz about any possibilities in the meantime.

Sean (Jan 21 2020 at 07:30):

yeah, this is a good franz question. I'm actually not finding anything in the way of examples that doesn't serialize to a string.

Sean (Jan 21 2020 at 07:31):

so towards that end, I think your earlier suggestion should be workable. just stash them individually with key "object.#"

Sean (Jan 21 2020 at 07:32):

Jeffrey Liu (Jan 21 2020 at 07:33):

Right, the problem with that approach is that I think I'd need to define a "get_object.#" function for each key, so I'm still limited in the end.

Jeffrey Liu (Jan 21 2020 at 07:34):

std::string
BrlcadObject::get_database() const
{
    return m_params.get_required<std::string>("database_path");
}


int
BrlcadObject::get_object_count() const
{
    return m_params.get_required<int>("object_count");
}


std::string
BrlcadObject::get_objects() const
{
    return m_params.get_required<std::string>("object_names");
}

Jeffrey Liu (Jan 21 2020 at 07:38):

Or actually, maybe what could be done is define a general std::string BrlcadObject::get_object() function that takes an int parameter that's used... it could potentially work

Sean (Jan 21 2020 at 07:38):

Sean (Jan 21 2020 at 07:40):

it can call up the count: int count = m_params.get_required<int>("object_count");
and then iterate over for (i=0; i < count; i++) {std::string oname = "object." + i; ... m_params.get_required<std::string>(oname); }

Jeffrey Liu (Jan 21 2020 at 07:41):

Oh, I think what I just mentioned is basically what you were talking about. Sorry, I didn't fully understand what you meant. I don't see why it wouldn't work, so I'll try testing it out when I get the chance.

Sean (Jan 21 2020 at 07:42):

and you'd return whatever data structure is the easiest to work with. maybe a std::vector<std::string> or a plain std::string* array or ... etc

Jeffrey Liu (Jan 21 2020 at 07:46):

Jeffrey Liu (Jan 21 2020 at 07:47):

I think I'll go to sleep for now, it's getting pretty late. I'll definitely try doing what you mentioned as soon as I can though

Jeffrey Liu (Jan 22 2020 at 04:02):

So I was taking a look at worker.c and do.c, but it looks like a lot of it is tied to rtuif and main.c (for example, model2view and view2model are both declared in main.c), so I don't think I can just directly call things like do_ae() or grid_setup(). I think I could just copy those functions into art.cpp and then adjust any variables accordingly for now, if that's fine, unless there's a better way to handle things?

Sean (Jan 22 2020 at 04:37):

@Jeffrey Liu You can just call them -- you just need to provide your own model2view and view2model globals defined in some source file.

Sean (Jan 22 2020 at 04:38):

defining the globals and just calling the existing functions would be MUCH more preferable to duplicating the code (harder to maintain long-term).

Jeffrey Liu (Jan 22 2020 at 11:34):

Yeah, that makes sense. I was worried that some of the stuff would be RTUIF specific, but I guess as long as I don't call those things, it's okay?

Jeffrey Liu (Jan 22 2020 at 17:18):

So, a couple updates. Doing what you mentioned with the object_names works as expected - I did have an issue with using a "." (the parameter parsing was weird because '.' is used as a path separator), but franz helped me get it working. I'm still having some trouble linking do.c and worker.c though, because they seem to also require functions that are defined in main.c or view.c (like memory_storage() or view_2init()).

Jeffrey Liu (Jan 22 2020 at 17:23):

Also strange how I'm getting some unresolved external symbols between things like do.c and opt.c, since they're both in the project?

Jeffrey Liu (Jan 22 2020 at 18:42):

Sorry, actually I didn't notice it before but there is an issue with the object arguments still. Even though they're separated, the object name with a space in the middle still doesn't get loaded. Do I need to add escape sequences for quotation marks to it?

Jeffrey Liu (Jan 23 2020 at 04:56):

Hey @Sean , I think I've got the azimuth and elevation math worked out (I'm using rt to see where the camera location would be, and then manually putting it in), so my last step would be to properly call grid_setup(), which I'm still struggling to set up. Could you help me with what I mentioned above?

Jeffrey Liu (Jan 23 2020 at 05:12):

For fun: rt perspective render with -a 35 -e 25 havocrt1.png vs art perspective render with -a 35 -e 25

Jeffrey Liu (Jan 23 2020 at 05:13):

Jeffrey Liu (Jan 23 2020 at 05:14):

I wish there was a better way to render without using skylight though (which doesn't require setting up the lights properly), the geometry is pretty hard to see as of now.

Jeffrey Liu (Jan 23 2020 at 06:59):

Jeffrey Liu (Jan 23 2020 at 07:01):

Jeffrey Liu (Jan 23 2020 at 07:02):

I changed the aspect ratio a little bit for the art one, which is why it's a bit different.

Jeffrey Liu (Jan 23 2020 at 07:04):

Sean (Jan 25 2020 at 05:48):

That's pretty awesome @Jeffrey Liu. Do you know if that's specifically an ortho camera or is it perspective with a wide angle?

Jeffrey Liu (Jan 25 2020 at 12:57):

This is a perspective camera with a wide angle, but I think it would be relatively easy to change since appleseed offers a PinholeCamera (perspective) as well as an OrthographicCamera (ortho).

Sean (Feb 05 2020 at 22:20):

Hey @Jeffrey Liu I really want to showcase the progress you made on the appleseed front. Do you think you can create a showcase image in appleseed of some brl-cad geometry?

Sean (Feb 05 2020 at 22:22):

could be an imported nurbs model from grabcad or perhaps a different sample model (we've shown havoc lots before, maybe m35). maybe ask franz if there's an easy way to create a default skylight or set a material so that it'll look more interesting than the default dark gray object on light blue background.

Sean (Feb 05 2020 at 22:22):

Jeffrey Liu (Feb 06 2020 at 01:28):

Sure! To be clear, when you say skylight, you mean some sort of directional light (instead of the ambient sky radiance being used right now), right? I can also set the sky and object material colors for now, so is there anything else you had in mind?

Jeffrey Liu (Feb 06 2020 at 01:49):

Or, looking at the appleseed built-in entities again, there's also a sun model. I can test the two to see which works better though.

Sean (Feb 08 2020 at 18:14):

@Jeffrey Liu I simply meant changing the rendering parameters so it's not so dark, whether by changing to different ambient light parameters, switching to "sun", or doing something similar that generalizes to other models

Sean (Feb 08 2020 at 18:15):

colors would be huge improvement to see since things like m35 and some others would really be impressive

Jeffrey Liu (Feb 08 2020 at 18:54):

Ah okay, I'll play around with the lighting to see what looks best. Colors might be a little difficult for now though - I know it's possible, but I'll probably have to take a deeper look into both rt and Appleseed.

starseeker (Feb 27 2020 at 19:00):

Jeffrey Liu (Feb 27 2020 at 20:30):

starseeker (Mar 14 2020 at 14:04):

@Jeffrey Liu Just wanted to check - what's the state of the art program in the main SVN repo? Can it render that havoc image as-is, or is some of the logic still in patches?

Jeffrey Liu (Mar 17 2020 at 12:37):

Shoot, sorry - I just saw this message. I don't completely remember the state of the progress when I last worked on it, but I don't think it's ready yet. For starters, the CMake still needs work because I was compiling the dll manually (brlcadplugin) in my own project.

Jeffrey Liu (Mar 17 2020 at 12:38):

Actually, now that I think about it, I think I completely forgot to commit my work (sorry about that!). I'll try to get that done today if I can. At the very least, it will keep the main repo up to date with what I have although the logic still won't be complete.

Sean (Mar 19 2020 at 05:58):

That would be awesome @Jeffrey Liu ... definitely want to get as much integrated as possible before the code diverges too much. You made awesome progress. We definitely want to keep it moving forward.

Jeffrey Liu (Mar 24 2020 at 13:57):

Sorry for such a long delay - I believe all of my latest work has been committed.

Jeffrey Liu (Mar 24 2020 at 14:06):

Hi @Mitesh , I saw that you were interested in working on this appleseed project. In the case that I don't get the chance to work on this for a while, here are just some general notes which may help:

Jeffrey Liu (Mar 24 2020 at 14:07):

Please tag me if you have any questions, right now there's a lot of manual set up required because the CMake isn't complete.

Jeffrey Liu (Mar 24 2020 at 14:10):

Also @Sean , could you let me know if everything committed correctly? I was getting errors because the two new files didn't have their svn:mime-type and svn:eol-style set, so I searched up what was best to use for .cpp and .h files.

Jeffrey Liu (Mar 24 2020 at 14:14):

Oops, one last thing I forgot. Just committed a second change - now everything should be up to date.

Sean (Mar 24 2020 at 20:09):

Sean (Mar 24 2020 at 20:10):

Sean (Mar 24 2020 at 20:12):

The commits themselves looked okay. The commit message could have said something more useful as it wasn't informative, but it looked okay at first glance.

Jeffrey Liu (Mar 24 2020 at 20:55):

Ah okay, sorry about the message - I wasn't sure about how lengthy I should've made it

Jeffrey Liu (Mar 24 2020 at 20:55):

I was just wondering about the svm:mime-type and stuff, because I'm not exactly sure what it's about

starseeker (Mar 25 2020 at 00:43):

starseeker (Mar 25 2020 at 00:45):

Quick and dirty - just hard-coded the output name - but got an image with: ./bin/art share/db/moss.g all.g

starseeker (Mar 25 2020 at 00:49):

@Jeffrey Liu No idea what those changes will do on Windows - only tested on Linux so far.

Sean (Mar 25 2020 at 02:07):

Mitesh (Mar 25 2020 at 04:04):

Thank you so much @Jeffrey Liu . I will quickly revise the older things and then try to cover this up

Jeffrey Liu (Mar 29 2020 at 16:22):

Awesome! It's great to see that it works for the most part for other people - I'll see if I can test the Windows side anytime soon.

Sean (May 13 2020 at 18:49):

Jeffrey Liu (May 15 2020 at 13:22):

Sure thing! Sorry about that... I said I would but I never got the chance. I'll definitely SVN update and try to compile it today. My AP exams are finally over!

starseeker (May 15 2020 at 14:02):

Jeffrey Liu (May 16 2020 at 19:30):

Thanks! It really is, now that I can get back to doing what I'd like to be doing.

Jeffrey Liu (May 17 2020 at 06:42):

Sorry about the hold up, I've been trying to compile, but unfortunately it seems like the find_package(Appleseed) still isn't working for me, and I forgot what I set manually in order to get it to work...

Jeffrey Liu (May 17 2020 at 06:42):

I tried -DAppleseed_ROOT to the Appleseed directory, but it still didn't work out for some reason, so I'm still testing

Jeffrey Liu (May 17 2020 at 08:07):

Ah I finally got it sorted out, I just had to set Appleseed_LIBRARY and Appleseed_INCLUDE_DIR manually.

Jeffrey Liu (May 18 2020 at 07:12):

Hm okay, so I'm still running into a couple issues because of the header file. I think the main issue is the fact that art.h is being used in brlcadplugin.cpp as well as art.cpp, even though brlcadplugin.cpp is supposed to compile into a dll while art.cpp uses those dll functions.

starseeker (May 18 2020 at 12:12):

@Jeffrey Liu OK, that's not too surprising - Linux let's me do a lot of things that don't work on Windows. You may need to shift some logic around - I took the straightest path to get something running on Linux, which undoubtedly cut too many corners on Windows.

Jeffrey Liu (May 18 2020 at 14:33):

Oh wait, it wasn't actually what I thought it was. I had to manually configure the project a little, but after that, just removing the extern "C" part of brlcad_hit() and brlcad_miss() declaration ended up allowing me to build it successfully.

Jeffrey Liu (May 18 2020 at 14:34):

starseeker (May 18 2020 at 15:13):

Probably not - I'll sometimes reflexively add that since it's needed a lot when C++ functions are exposed API.

starseeker (May 18 2020 at 15:14):

Go ahead and get it running on Windows - Linux is relatively easy to fix, so we can get it later.

Jeffrey Liu (May 19 2020 at 19:45):

Alright, I've finally gotten it to render something again, but it looks like somethings up with the option parsing for some reason. I guess I'll need to look at that first.

Sumagna Das (May 19 2020 at 19:46):

Sean (May 19 2020 at 19:46):

Sumagna Das (May 19 2020 at 19:47):

Jeffrey Liu (May 19 2020 at 19:47):

Sean (May 19 2020 at 19:47):

Sean (May 19 2020 at 19:48):

Sumagna Das (May 19 2020 at 19:48):

Sean (May 19 2020 at 19:48):

Jeffrey Liu (May 19 2020 at 19:49):

Not too much, I just changed the extern "C" part of a couple function declarations. I have a question about the find_library() and find_path() in FindAppleseed.cmake though - for the HINT keyword, does CMake only check the paths from that path?

Jeffrey Liu (May 19 2020 at 19:51):

So what I mean to say is, CMake was having trouble finding appleseed.lib, even though I was providing Appleseed_ROOT. In the end, I had to specify Appleseed_LIBRARY to the actual path, which was {appleseed}/sandbox/lib/appleseed.lib

Jeffrey Liu (May 19 2020 at 19:52):

find_library (Appleseed_LIBRARY
    NAMES appleseed
    HINTS
    ${Appleseed_ROOT}
    PATH_SUFFIXES
    lib64
    lib
    )

Jeffrey Liu (May 19 2020 at 19:55):

I believe I may have had a similar issue with Appleseed_INCLUDE_DIR as well. I think a simple fix would be to just make the hint a little bit more specific for both, but I'm a bit hesitant because I'm not too experienced with CMake.

Jeffrey Liu (May 19 2020 at 19:57):

Sean (May 19 2020 at 20:35):

All the logic for finding appleseed is in the FindAppleseed.cmake file, and it looks like ROOT is only used as a HINT search path, so you're on the right track. It's strange that it didn't find it if you specified a path containing appleseed.lib

Sean (May 19 2020 at 20:37):

The thing to do would be to either run cmake in trace mode or read the output logs in build/CMakeFiles/CMakeError.log to see if maybe there's some reason it failed to find it.

Sean (May 19 2020 at 20:37):

Sean (May 19 2020 at 20:38):

you're the only one working in this area, so you're welcome to experiment with changes to the FindAppleseed.cmake file. whatever is needed -- getting 'art' working is kind of a huge deal.. ;)

Sean (May 19 2020 at 20:39):

the extern "C" bits sound strange. that may beg for something else depending on what you changed. windows has slightly different linking rules than linux by default in terms of how it resolves dlls and exes.

Sean (May 19 2020 at 20:41):

ah, but that's not what's going on here. just saw your commit. yeah, that extern "C" was wrong. it's defined in the cpp file without C linkage.

Jeffrey Liu (May 19 2020 at 23:22):

Great, I had a couple of things I wanted to try out. I'll try running the CMake again and checking out the output logs first though.

Jeffrey Liu (May 19 2020 at 23:25):

Sean (May 19 2020 at 23:25):

Jeffrey Liu (May 20 2020 at 00:14):

Nothing much, it looks like the functions were commented out for the Linux build, and usage.cpp needed to be added.

Jeffrey Liu (May 20 2020 at 00:18):

Here's the CMakeError.log, but I don't think there's any mention of appleseed. CMakeError.log

Jeffrey Liu (May 20 2020 at 01:02):

starseeker (May 20 2020 at 01:11):

If you have a new enough CMake (3.17 I think?) you can pass the --debug-find option to CMake on the command line - that may help debug what's going on with the package searching.

Jeffrey Liu (May 20 2020 at 01:30):

Sean (May 20 2020 at 15:14):

@Jeffrey Liu naming the variable _ROOT may be misleading -- find_library is going to look in the specified directory, which probably isn't the prefix/root that appleseed was configured for but, rather, was something like $prefix/lib or $prefix/share/lib or similar. The find script might do better searching ROOT/lib as the hint.

Sean (May 20 2020 at 15:15):

Jeffrey Liu (May 23 2020 at 22:27):

Hm yeah, that makes sense. In that case, I do think that FindAppleseed should be updated a little bit.

Jeffrey Liu (May 23 2020 at 22:27):

Sean (May 24 2020 at 19:41):

@Jeffrey Liu you're more than welcome to update FindAppleseed.. it almost certainly needs updating if I'm understanding the issue. It was probably written quickly.

Sean (May 24 2020 at 19:41):

Jeffrey Liu (May 27 2020 at 22:50):

Alright, so using the more specific paths did actually help CMake find everything properly. There is a slight issue though: the path to appleseed.lib was ${Appleseed_ROOT}/sandbox/lib/vc141/Ship, which I'm pretty sure is specific to MVSC and the debug/release configuration used for Appleseed. I don't think hardcoding that path is a good idea, but I'm not sure how I would be able to efficiently encompass all of the possible paths for different compilers and configurations .

Jeffrey Liu (May 27 2020 at 22:51):

I guess just listing them all out could be an option? Or maybe there is some CMake variable to determine platform or configuration that I'm unaware of?

Sean (Jun 02 2020 at 07:32):

This is probably a better question for @starseeker but that sounds like a rando-path that Appleseed decided to use (the "Ship" part in particular). I see no mention of it. So it wouldn't be entirely inappropriate for it to be hard-coded at least in a relative path form into the FindAppleseed logic.

Jeffrey Liu (Jun 03 2020 at 05:47):

I think the Ship part had to do with the configuration mode, because I also had another Debug directory (which was probably created when I compiled Appleseed in Debug mode). And I believe vc141 is related to something like the MSVC version? That's why I'm a bit reluctant to just directly hardcode that path, because it seems like I'm not accounting for other paths.

Jeffrey Liu (Jun 03 2020 at 05:54):

That being said, I guess this is more of a side thing that's a bit lower in priority. I'm thinking of trying to implement the BRL-CAD colors next and see how that works out.

starseeker (Jun 03 2020 at 14:10):

@Jeffrey Liu Yeah, I wouldn't worry too much about the Find paths - unless things are reasonably standard in the upstream software that's a challenge, and it's orthogonal to the main effort - if Appleseed rendering fully pans out we'll do what we need to do to to get things set up and working.

Sean (Jun 04 2020 at 15:43):

That sounds great! Let me know if you need pointers in working with colors. Colors are a little tricky as objects can have a color attribute set and objects can be categorically colored based on a global color table.

Sumagna Das (Jun 04 2020 at 16:08):

Sean (Jun 04 2020 at 16:16):

@Jeffrey Liu You'll discover that there's unfortunately not a simple interface yet as colors have kind of evolved over time as needed. There's a TODO item to create such an interface:

* need routine that returns a color given a path, similar to
  rt_comb_get_color() but full path so that inheritance is taken into
  account and colors set correctly.

The closest is probably color_soltab() in src/libged/display_list.c as it has the crux for a given object, but what's needed is something that works on a path.

Jeffrey Liu (Jun 09 2020 at 17:35):

Alright thanks! Since school's about to end, I'll have a lot more free time on my hands. I'll start by taking a look at the files you recommended.

Jeffrey Liu (Jun 25 2020 at 04:56):

So, I've been looking into it but it looks like implementing colors might be pretty difficult. The issue is that I'd be assigning a material to a single "BRL-CAD object instance," which makes it all the same color. However, this same instance is the same one that initializes all of the BRL-CAD rt stuff, so I'm a bit stuck. I'm certain that appleseed must have some sort of way to manage different colors for a single object instance, but I think that may involve textures instead.

Sean (Jun 25 2020 at 12:21):

@Jeffrey Liu appleseed and most modern renderers use a concept of materials to control color. You create a material object, can specify colors there, and set objects to that material.

Sean (Jun 25 2020 at 12:25):

Sean (Jun 25 2020 at 12:26):

appleseed goes even further where you can then perform color transforms and all sorts of other operations on a material using a shader network, but you can pretty much ignore all of that.

Jeffrey Liu (Jul 05 2020 at 00:51):

Right, so my concern was being able to assign multiple colors. I'm pretty sure that currently, only a single material can be assigned to the entire BRL-CAD geometry because of the way the BRL-CAD instance works, so I'm not completely sure how I'd be able to map colors to individual objects and such.

Jeffrey Liu (Jul 05 2020 at 01:00):

Worst case scenario, I can try to rewrite art.cpp so that an object instance is created for each object, but I'm not completely sure how the rt resources will be distributed in that case. At the very least, it sounds like there would be a lot more overhead involved when raytracing.

Jeffrey Liu (Jul 05 2020 at 01:03):

Another issue involved with that might be initializing the raytracing application again when, for example, the appleseed project is being opened again after art.cpp has already been called.

Jeffrey Liu (Jul 05 2020 at 01:08):

However, on the other hand, there are a lot of pros involved with separating each BRL-CAD object into individual instances because it kind of makes more sense intuitively. Colors would be a lot easier to manage, and I imagine it would be easier to manage if different objects were different materials (plastic, glass, etc). if it's possible, I think it could be worth pursuing.

starseeker (Jul 05 2020 at 03:33):

Sean (Jul 08 2020 at 18:40):

The way we usually deal with embedded contexts like this is to map at the region level. So you'd create a an art object for each region instead of just the top-level object, calculate bounding boxes for all of them, and appleseed will do it's traversal accordingly.

Performance is unlikely an issue. If anything, region-level lets appleseed be a lot smarter about ray traversal for really complex geometries instead of relying on librt traversal for all rays that get near. Resource-wise, librt should just work and do the right thing -- one plus side of the global resource states.

Sean (Jul 08 2020 at 18:41):

there aren't multi-material regions -- by definition they represent a single material, so the mapping to a display material becomes naturally 1-to-1 also, so it should solve that problem as well.

Jeffrey Liu (Jul 14 2020 at 21:40):

Right, but if I'm understanding correctly, I feel like it'll be difficult to, say, initialize the rt application and be able to share it among object instances. Right now, since everything is under one object, it's easy for that object to simply just initialize the rt application. Once the regions are split into different objects, I'm struggling to think of a way for that to work out.

Jeffrey Liu (Jul 14 2020 at 21:46):

This is the part that concerns me, which is in the constructor, and the resources are object attributes:

ap = static_cast<application*>(bu_calloc(1, sizeof(application), "appleseed"));
    resources = static_cast<resource*>(bu_calloc(1, sizeof(resource) * MAX_PSW, "appleseed"));

    char title[1024] = { 0 }; /* optional database title */
    size_t npsw = 1; /* default number of worker PSWs*/

    /* load the specified geometry database */
    rtip = rt_dirbuild(path, title, sizeof(title));
    if (rtip == RTI_NULL)
    {
    fprintf(output, "Building the database directory for [%s] FAILED\n", path);
    fflush(output);
    }

    for (size_t i = 0; i < MAX_PSW; i++)
    {
    rt_init_resource(&resources[i], i, rtip);
    RT_CK_RESOURCE(&resources[i]);
    }

    /* display optional database title */
    if (title[0])
    {
    fprintf(output, "Database title: %s\n", title);
    fflush(output);
    }

    /* parse object arguments */
    const char** objv = (const char**)bu_calloc(objc + 1, sizeof(char*), "obj array");
    for (int i = 0; i < objc; i++)
    {
        objv[i] = objects.at(i).c_str();
    }

    /* include objects from database */
    if (rt_gettrees(rtip, objc, objv, npsw) < 0)
    {
    fprintf(output, "Loading the geometry for [%s] FAILED\n", objects[0].c_str());
    fflush(output);
    }

    /* Prepare database for raytracing */
    if (rtip->needprep)
    rt_prep_parallel(rtip, 1);

    /* Initialize values in application struct */
    RT_APPLICATION_INIT(ap);

    /* configure raytrace application */
    ap->a_onehit = -1;
    ap->a_rt_i = rtip;
    ap->a_hit = brlcad_hit;
    ap->a_miss = brlcad_miss;

Jeffrey Liu (Jul 14 2020 at 21:49):

I guess what I could try doing is making all of those attributes static, and then have a single object instance initialize everything while the others wait for the initialization to complete?

Sean (Jul 14 2020 at 21:52):

Shouldn't be difficult at all, in fact you shouldn't really need to do anything special/different.

Sean (Jul 14 2020 at 21:53):

Resources are initialized per cpu core. They have nothing to do with the object or application structure. They're basically book-keeping structures used by librt parallelism.

Sean (Jul 14 2020 at 21:54):

so those resource structures just need to be initialized prior to rendering, and provided to the application structure.

Sean (Jul 14 2020 at 22:02):

similarly the application structure is once per application, and doesn't need to change. the resources are set into it, which makes it safe for multithreaded ray shooting.

Sean (Jul 14 2020 at 22:08):

the only thing that really changes is the interface to appleseed. instead of giving appleseed one bounding box / object, you need to provide a box for each region. they can all be configured to go through the same app structure like they are doing now.

Sean (Jul 14 2020 at 22:09):

even the dirbuild shouldn't need to change (this is ultimately what is turned into the rt_i instance that goes into the app structure.

Sean (Jul 14 2020 at 22:10):

if you get lost, I can probably give more specific pointers in the code or help work with you on this.

Jeffrey Liu (Jul 20 2020 at 07:39):

Ah ok, thank you for the explanation about librt! I think that does clear some confusion. Sorry for taking so long to respond all the time - I've been a bit occupied. I'll take a look at it again as soon as I can.

Jeffrey Liu (Jul 20 2020 at 07:42):

I think my main source of confusion was that an object would need to be created for each region, so I wasn't sure how the application structure could be shared, but I guess it can just be kept as a static variable.

Sean (Jul 20 2020 at 23:04):

@Jeffrey Liu static var or better if you can find a way to pass it around. I assume appleseed has some sort of data pointer you could set it to. the application structure itself has a user data pointer where you can stash additional information.

Jeffrey Liu (Jul 27 2020 at 14:19):

Sean (Jul 27 2020 at 14:28):

Sean (Jul 27 2020 at 14:30):

yeah, looks like you already have what you need. instead of a data pointer, he's using inheritance. see how BrlcadObject inherits from asr::ProcecuralObject

Sean (Jul 27 2020 at 14:30):

Jeffrey Liu (Jul 27 2020 at 14:31):

Sean (Jul 27 2020 at 14:31):

you'll just pass the same ap, rtip, and resources into ALL BrlcadObject objects.

Sean (Jul 27 2020 at 14:32):

Sean (Jul 27 2020 at 14:34):

ah, i take it back -- there are some subtle changes needed. I see the constructor calls configure_raytrace_application, which is where it actually calls rt_dirbuild, initializes the resources, and inits the ap structure. that code needs to get pulled higher up before BrlcadObject is constructed.

Sean (Jul 27 2020 at 14:36):

looks like you can pull it into BrlcadObjectFactory::create() once you know the name of the object(s) being rendered

Jeffrey Liu (Jul 27 2020 at 14:39):

Ah, I see. Thanks for the advice! I'll test out the Factory creation stuff this week.

Sean (Jul 27 2020 at 14:39):

Sean (Jul 27 2020 at 14:40):

the only issue might be what you ran into with art.cpp and the plugin calling the two different constructors. look like they both need to call the one art.cpp is using (where rtip, resources, and application struct are passed in)

Jeffrey Liu (Jul 27 2020 at 14:42):

Right. But you mentioned that BrlcadObjectFactory::create() might be able to pass the resources in instead, right? Also, if I'm understanding correctly, is it perfectly safe for multiple objects to hold the same rtip, resources, and application struct?

Sean (Jul 27 2020 at 14:46):

Sean (Jul 27 2020 at 14:48):

that's why there are resources ... those are CPU resources used during ray tracing.

Sean (Jul 27 2020 at 14:53):

the gist is that you create one main app structure where you set the resources and rtip.

Sean (Jul 27 2020 at 14:53):

Jeffrey Liu (Jul 27 2020 at 14:54):

That makes a lot of sense, I don't know why I initially thought that it would be dangerous for there to be multiple pointers to the same resource. Thank you again for the help!

Sean (Jul 27 2020 at 14:55):

Sean (Jul 27 2020 at 14:56):

the typical multithreaded use can be see in src/rt/worker.c:do_pixel() ... look for the "struct copy" line where it tells that specific ap which cpu resource to use.

Jeffrey Liu (Jul 27 2020 at 15:01):

Ah, I see it. In this case, that's only necessary because it's being multithreaded, right? So in this case, where it's still single threaded at the moment, that's not something I have to worry about yet, is it?

Sean (Jul 27 2020 at 16:01):

@Jeffrey Liu you are worrying about it (correctly) already... look at BrlcadObject::intersect() instead of creating a copy of the AP, you just set the resource and call rt_shootray().

Sean (Jul 27 2020 at 16:01):

Sean (Jul 27 2020 at 16:02):

if that's not working in parallel, that would probably be because of multiple threads overwriting that resource - creating a copy of the AP should solve it..

Sean (Jul 27 2020 at 16:02):

Jeffrey Liu (Jul 27 2020 at 17:06):

Multithreading with appleseed is definitely something I'll be looking into soon. For now though, I'm going to focus on splitting the BRL-CAD object into regions/instances, and then work on the color rendering.

Jeffrey Liu (Jul 27 2020 at 17:07):

I remember there was some issue with multithreading before, but I didn't really have the knowledge to debug it at the time. Hopefully, it's something that can be sorted out soon.

Sean (Jul 27 2020 at 17:20):

if there was an issue, it's almost certainly that simultaneous use of the same ap structure. each ray should have its own.

Sean (Jul 31 2020 at 06:18):

@Jeffrey Liu any progress, need me to help with it? I feel like you're super close!

Jeffrey Liu (Aug 06 2020 at 00:45):

Not yet sorry - I've been pretty busy recently and, well, I've also been without power for the past two days. Hopefully I'll get to look at it soon, I definitely have a solid idea as to what needs to be done.

Jeffrey Liu (Aug 06 2020 at 00:46):

As a side note, do you think I could create a wikipage for this project at some point? I think it would help me and other contributors keep track of progress, create a to-do list, and so on.

Jeffrey Liu (Aug 06 2020 at 01:06):

And... 5 minutes later power is restored. I'll try to take a look at it tonight then.

Jeffrey Liu (Aug 06 2020 at 03:50):

Hm ok, so I do have a couple of "questions" and I would like to hear someone else's opinion on some things. Right now, since there's only one overarching object, it stores parameters like the object count and geometry file path. I guess the most straightforward way is just to make it so that each object ends up storing these parameters, but it seems a bit inefficient. Are there any better alternatives?

Jeffrey Liu (Aug 06 2020 at 03:52):

Other than that, I think everything else is pretty straightforward - when the appleseed project is opened by appleseed, the BrlcadObjectFactory should be able to configure brlcad raytracing in its constructor, which it can then pass down to the objects.

Jeffrey Liu (Aug 13 2020 at 22:05):

Sean (Aug 14 2020 at 17:20):

Hi @Jeffrey Liu sorry for the delay, I've been really deep in non-fun non-coding work this past week, so I'm playing catch up.

Sean (Aug 14 2020 at 17:23):

Sean (Aug 14 2020 at 17:26):

Depends what the parameters are, but I wouldn't worry about efficiency unless it's visibly causing a problem. There's a heck of a lot of room to create hundreds of thousands of objects and not have it really affect performance, or for performance to be optimizable in other ways.

Sean (Aug 14 2020 at 17:26):

Sean (Aug 14 2020 at 17:27):

geometry file path sounds like a string pointer, which really should only matter for debugging or maybe uniqueness testing on creation.

Sean (Aug 14 2020 at 17:29):

Remember that there's two modes of operation. There's the 'art' application binary that is intended to be stand-alone and be a drop-in replacement for rt. Then there's the appleseed plugin that hooks into librt and calls it for ray tracing. The 'art' application binary hopefully can use the appleseed plugin (or at least use the same code), but it's not strictly necessary.

Sean (Aug 14 2020 at 17:29):

Jeffrey Liu (Aug 16 2020 at 18:41):

Awesome, I'll get started on the wiki soon. I agree with you on the parameters - I guess it isn't that big of a deal. The geometry file path, however, is used by the application in order to actually get the geometry.

Jeffrey Liu (Aug 16 2020 at 18:44):

I'm a bit confused by this. My understanding was that the 'art' application binary isn't necessarily stand-alone, and still uses librt to test intersections with BRL-CAD geometry. It's true that there are two modes to actually render the image (either directly through art.exe or by opening the generated project through appleseed), but don't both methods rely on librt?

Sean (Aug 16 2020 at 19:15):

I meant stand-alone in the sense that it's a binary application that isn't reliant upon the appleseed studio runtime, not that it doesn't require librt or appleseed libs.

Sean (Aug 16 2020 at 19:15):

Jeffrey Liu (Aug 16 2020 at 20:21):

Ah ok, thank you for the clarification! I thought I had mistaken something this whole time. I created the wiki-page at https://brlcad.org/wiki/Appleseed, but I've only updated the to-do list for now. Once I get back to my computer, I'll start on the other sections as well.

Sean (Aug 18 2020 at 05:25):

Jeffrey Liu (Sep 29 2020 at 22:27):

Hi, sorry for being so inactive recently. I've been pretty caught up in school/college apps, which is why I kinda wanted to document the appleseed progress beforehand.

Jeffrey Liu (Sep 29 2020 at 22:38):

Unfortunately, I'm not sure how much I can contribute until maybe even January. However, if anyone is interested on working on the project in the meantime, I'd be happy to provide whatever assistance I can.

Sean (Sep 30 2020 at 15:08):

Hi @Jeffrey Liu it's understandable. We're all getting tugged in different directions. Just spent a week with my main dev laptop fully disassembled while I did some repairs/upgrades. Kind of disruptive. :)

Sean (Sep 30 2020 at 15:11):

That said, I'll probably be calling on you for some assistance if you think you're not going to be able to work on it through the rest of the year. We can't go too long without progress or the code and knowledge gets stale/lost and puts everything at risk.

You made amazing progress, so hoping to at least get a baseline capability rolled out into user hands (e.g., a colorless single-threaded 'art' binary).

Jeffrey Liu (Oct 06 2020 at 17:17):

Jeffrey Liu (Jan 11 2021 at 16:20):

Hi, just wanted to check-in to say that I should have some more time on my hands now - I'll take a look at the source code again and catch up on what it is I was planning on doing! Now kinda glad that Appleseed wiki was created.

starseeker (Jan 14 2021 at 14:00):

Sean (Feb 03 2021 at 03:38):

@Jeffrey Liu Ditto, glad to hear you have more time on your hands! Me too soon, woot!

Jeffrey Liu (Feb 13 2021 at 19:51):

That's great to hear! Sorry, for some reason I didn't receive any Zulip notifications. I've still been a little busier than anticipated, and taking a few months away definitely made me forget my understanding about a lot of the code, but hopefully I'll have something commit-worthy in a week or two.

Jeffrey Liu (Feb 14 2021 at 18:12):

so I tried SVN updating to the latest commit and rerunning CMake, but I'm getting a strange error where it says some .g object already exists in db/*, but when I check db\, only their .asc counterparts are there. Am I using CMake incorrectly here?

Erik (Feb 14 2021 at 18:34):

.asc would be the source directory, are you using the src root as your build dir?

Jeffrey Liu (Feb 14 2021 at 19:47):

Jeffrey Liu (Feb 14 2021 at 23:03):

starseeker (Feb 14 2021 at 23:20):

First suggestion is to make sure you're building from a clean build dir - there are lots of strange intermediate states that are hard to diagnose if the generated CMake outputs and the CMake build files aren't in sync.

Jeffrey Liu (Feb 14 2021 at 23:58):

Alright thanks, I guess I'll just do that then. I was just concerned that Ill forget about files that I manually arranged for Appleseed.

starseeker (Feb 15 2021 at 00:03):

You can always make a new build directory and leave the old one, unless you're too tight on space

Jeffrey Liu (Feb 15 2021 at 04:22):

Sean (Feb 18 2021 at 07:12):

Any progress building appleseed @Jeffrey Liu ? I haven't checked their latest in a while...

Jeffrey Liu (Feb 18 2021 at 19:28):

Do you mean the Appleseed repository itself? I haven't tried building it recently, but the appleseed project in BRL-CAD seems to build with enough configuration.

Sean (Feb 19 2021 at 07:44):

you mean it builds against the latest appleseed? That's good to know, even better actually. :)

Jeffrey Liu (Feb 21 2021 at 15:59):

Ah I just meant I haven't built the latest appleseed recently. I can try to after finishing my changes; I don't suspect it should affect the work in any way.

Jeffrey Liu (Feb 21 2021 at 16:39):

So I'm encountering another dilemma when trying to split the regions into separate appleseed objects. rtip is supposed to load the geometry instance into the application structure, but since each appleseed object is now only supposed to specify a specific region of the BRL-CAD geometry, it seems like I can't just load the same raytrace instance for each appleseed object (or else the raytracing will always intersect the same geometry for each appleseed object). Is there any way to circumvent this?

Jeffrey Liu (Feb 21 2021 at 16:41):

One idea that comes to mind is to prepare different rtips for each object, and then set ap.a_rt_i = rtip before intersecting each object. However, that sounds pretty inefficient and it seems like it would cause issues if multithreading were ever implemented.

Jeffrey Liu (Feb 21 2021 at 16:42):

Sean (Feb 23 2021 at 20:08):

@Jeffrey Liu first thought is that while using the same rtip will result in it always testing against the same geometry, it should/could still work like that. Not optimal of course performancewise, but it shouldn't be a problem. You'd just have to filter on only regions of interest for each appleseed object.

Sean (Feb 23 2021 at 20:13):

I think you're on the right track with the latter approach, though -- you can have a different rtip (and matrix) for each region and a corresponding appleseed object that sets that rtip during setup.

Sean (Feb 23 2021 at 20:14):

Note multithreaded access of rtip isn't/shouldn't be a problem -- librt accesses rtip in parallel as it is. You'll just have to map threads to a cpu identifier and make sure librt "resources" are initialized.

Sean (Feb 23 2021 at 20:21):

Note that breaking things up by region really isn't any different than supporting multiple render paths. Given appleseed is driving, you will have an application instance for each thread, so there's not contention within that structure. The rtip structures can be accessed in parallel by multiple threads just fine, so you'll just have an rtip for each region and set it in that thread-specific application structure.

Sean (Feb 23 2021 at 20:21):

Jeffrey Liu (Mar 08 2021 at 05:30):

I think so... Sorry for such a late response. So would you recommend using a different rtip for each region, or using a filter on regions of interest? If it's the latter, is there an example I could use as reference?

Sean (Mar 08 2021 at 14:35):

Jeffrey Liu (Jul 14 2021 at 22:58):

Hi, sorry again for not being able to work for so long - work, school, and college has really been a lot to handle. On the bright side, I got a new laptop so hopefully compiling things won't be an overnight process anymore, and developing things can be a bit more enjoyable. Although I can't guarantee that I'll be able to contribute anytime soon, I just wanted to catch up on things. I noticed that we switched over to GitHub - does our development process still involve committing directly to master?

starseeker (Jul 15 2021 at 17:59):

Jeffrey Liu (Jul 15 2021 at 23:15):

Sean (Jul 18 2021 at 20:31):

For now, yes, but you are welcome to work in a branch or work via pull requests to involve others, etc. Whatever works for you.

Jeffrey Liu (Jul 19 2021 at 05:19):

Jeffrey Liu (Jul 19 2021 at 05:20):

I am getting one error for distcheck though, I feel like I had this error before but I forgot if it was a problem or not.

Sean (Jul 20 2021 at 06:37):

Jeffrey Liu (Jul 20 2021 at 15:05):

I believe the error said something like the repo does not match the dist or something - I'll try compiling again to see what it is

Jeffrey Liu (Jul 20 2021 at 15:12):

This is it:

CUSTOMBUILD : error : Distcheck cannot proceed until build files and repo are in sync (set
3>  -DFORCE_DISTCHECK=ON to override)

starseeker (Jul 20 2021 at 21:27):

Jeffrey Liu (Jul 20 2021 at 22:27):

Jeffrey Liu (Jul 20 2021 at 22:28):

Also something I've never really figured out concretely - when a CMakeLists.txt gets updated, what exactly do I need to "refresh?" Should I delete the whole build directory and try again? I've tried to run cmake .. again in the same build file, but it always seems like the generation or configuration never gets updated properly.

bch (Jul 20 2021 at 22:28):

Tip of git main endeavours to always be buildable, and is recommended place from which to build new work?

Jeffrey Liu (Jul 20 2021 at 22:30):

Yes, I believe this is true but it may not always be tested across all platforms

bch (Jul 20 2021 at 22:51):

Jeffrey Liu (Jul 20 2021 at 22:53):

starseeker (Jul 21 2021 at 00:39):

tip of main is not guaranteed to always be building, but usually will be. Part of the motivation for moving to Github was to leverage the CI system they have created, and we are starting to do so.

starseeker (Jul 21 2021 at 00:42):

@Jeffrey Liu The reason it failed for you earlier was because you were doing a distcheck build, and the main CI build doesn't run the full distcheck process. I just added a test that will catch the most typical reason for a distcheck failure (failing to list files for the repository verification, which was the failure you were seeing.)

starseeker (Jul 21 2021 at 00:42):

starseeker (Jul 21 2021 at 00:43):

starseeker (Jul 21 2021 at 00:45):

That's an evolving process - as I learn new tricks I'm adding more steps (for example, I recently enabled the Qt build elements for testing.)

starseeker (Jul 21 2021 at 00:46):

The runners will time out if they go too long, so individual tests can only be so long. (A complete distcheck-full, for example, would be WAAAY too much...)

starseeker (Jul 21 2021 at 00:51):

@Jeffrey Liu The most reliable thing to do is delete the build directory and start fresh. In many cases you don't have to, but there are situations where stale outputs can cause problems. If you're seeing strange issues, a clean build is always the first thing to test.

Jeffrey Liu (Jul 21 2021 at 03:13):

That makes sense, I was just wondering if there was any faster way because it still does add up to quite some time. As for the distcheck build, I was just building the generated CMake solution for VS 2019 - should I be building the ALL_BUILD project?

Jeffrey Liu (Jul 21 2021 at 03:13):

Also am a little curious about how all the CI stuff works, I haven't really worked with CI/CD stuff but am definitely interested

Sean (Jul 21 2021 at 05:21):

Yes, that is our policy (HACKING mentions it as well). Devs committing to main are expected to at least reasonably expect that their changes compiles on the platform they're using, not knowingly break other platforms, and to respond/fix quickly or revert when informed of changes they made do break other platforms.

Sean (Jul 21 2021 at 05:22):

The STABLE branch takes that a step further, nominally asserting that it compiles cleanly across multiple platforms and not allowing direct commits/merges without multiplatform testing.

starseeker (Jul 21 2021 at 12:46):

Yes, you'll want to build the ALL_BUILD target for Visual Studio. You don't have to build the distcheck target for day to day development - you can just do "make -j8" or "ninja" (if you're configuring using the Ninja generator (cmake -G Ninja) - ninja can sometimes build faster than make.)

starseeker (Jul 21 2021 at 12:53):

starseeker (Jul 21 2021 at 12:54):

CI/CD is a general concept - Actions are just Github's implementation - but for the moment they're the system we're targeting.

Jeffrey Liu (Jul 21 2021 at 19:35):

Jeffrey Liu (Aug 20 2021 at 06:08):

cmake .. -DAPPLESEED_ROOT="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed" -DBRLCAD_PNG=SYSTEM -DBRLCAD_ZLIB=SYSTEM -DZLIB_LIBRARY="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed\windows-deps\stage\vc141\zlib-debug\lib\zlibd.lib" -DZLIB_INCLUDE_DIR="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed\windows-deps\stage\vc141\zlib-debug\include" -DPNG_LIBRARY="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed\windows-deps\stage\vc141\libpng-debug\lib\libpng16_staticd.lib" -DPNG_PNG_INCLUDE_DIR="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed\windows-deps\stage\vc141\libpng-debug\include"

starseeker (Aug 20 2021 at 13:19):

Hmm. I've not tried overriding on WIndows in that particular way - what if you set ZLIB_ROOT to the parent directory of the zlib installation?

Jeffrey Liu (Aug 20 2021 at 13:41):

Interesting, I'll try that out. I just did it that way since it seemed like those were the two variables missing.

Jeffrey Liu (Aug 20 2021 at 13:42):

Sean (Aug 20 2021 at 15:19):

I wonder if that's the same issue I've run into with zlib... There's some build configuration I keep running into where I get zlib NOTFOUND even though it was set to bundled. I've only run into it 2 times I think, and each time was fixed by just doing it again. Maybe a race/ordering issue? Or something with the depth and subbuilds?

Jeffrey Liu (Aug 20 2021 at 16:22):

I don't think I'm familiar enough with CMake to know why ZLIB_ROOT works instead, but maybe it's also because CMake expects to automatically generate the two variables?

Jeffrey Liu (Aug 20 2021 at 16:24):

-- Configuring done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
PNG_LIBRARY_RELEASE (ADVANCED)
    linked by target "libged-static" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/libged
    linked by target "libged" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/libged
    linked by target "libdm" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/libdm
    linked by target "libdm-static" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/libdm
    linked by target "libicv" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/libicv
    linked by target "libicv-static" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/libicv
    linked by target "fb-png" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/fb
    linked by target "png-fb" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/fb
    linked by target "bw-png" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/util
    linked by target "pix-png" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/util
    linked by target "png-bw" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/util
    linked by target "png-pix" in directory C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/brlcad/src/util

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

I'm curious, does it matter which library is used when building Debug/Release? Just to be safe, I've been trying to use all the debug libraries built by appleseed, but this message clearly specifies Release.

Jeffrey Liu (Aug 20 2021 at 16:25):

//Directory containing libpng headers.
PNG_INCLUDE_DIRS:STRING=C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/libpng-debug/include

//libpng
PNG_LIBRARIES:STRING=PNG_LIBRARY_RELEASE-NOTFOUND

//Path to a library.
PNG_LIBRARY_DEBUG:FILEPATH=C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/libpng-debug/lib/libpng16d.lib

//Path to a library.
PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND

//Path to a file.
PNG_PNG_INCLUDE_DIR:PATH=C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/libpng-debug/include

//No help, variable specified on the command line.
PNG_ROOT:UNINITIALIZED=C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed\windows-deps\stage\vc141\libpng-debug

Jeffrey Liu (Aug 20 2021 at 16:28):

So the debug library is being found, which makes sense because I set the root directory as the libpng-debug directory, but it's also asking for release?

starseeker (Aug 20 2021 at 16:40):

That's strange - libged is using PNG_LIBRARIES, which is supposed to be set in src/other/ext/png.cmake to either the png target (if building bundled) or (if defined) ${PNG_LIBRARY_RELEASE} or ${PNG_LIBRARY_DEBUG} - i.e., the contents of those variables.

starseeker (Aug 20 2021 at 16:41):

Debug builds of MSVC compilations aren't redistributable, so unless we're in a very specific debugging scenario where we need to walk into the png library we want the release build.

starseeker (Aug 20 2021 at 16:43):

It looks as if the test "if (DEFINED PNG_LIBRARY_RELEASE)" is passing despite PNG_LIBRARY_RELEASE having a "NOTFOUND" value.

Jeffrey Liu (Aug 20 2021 at 16:44):

Ah okay, so in general, is it better to use the release version for these libraries?

starseeker (Aug 20 2021 at 16:44):

@Jeffrey Liu in src/other/ext/png.cmake try changing the last block setting PNG_LIBRARIES to the following:

  if (PNG_LIBRARY_RELEASE)
    set(PNG_LIBRARIES ${PNG_LIBRARY_RELEASE} CACHE STRING "libpng" FORCE)
  else (PNG_LIBRARY_RELEASE)
    set(PNG_LIBRARIES ${PNG_LIBRARY_DEBUG} CACHE STRING "libpng" FORCE)
  endif (PNG_LIBRARY_RELEASE)

starseeker (Aug 20 2021 at 16:45):

If that works we'll need to update the logic in the repo - I hadn't noticed that a NOTFOUND setting would also result in DEFINED passing, but it seems it does.

Jeffrey Liu (Aug 20 2021 at 16:45):

starseeker (Aug 20 2021 at 16:55):

Looks like I'm just always using ZLIB_LIBRARY_RELEASE in the zlib.cmake logic - I suppose I should do the same thing as we do for PNG so it's consistent.

starseeker (Aug 20 2021 at 16:56):

What I can probably do is use the DEFINED test on ZLIB_LIBRARIES and PNG_LIBRARIES to see if the user has specified something in particular and not override it - otherwise, go with release if defined and if that doesn't work try debug.

starseeker (Aug 20 2021 at 16:58):

In retrospect I'm not surprised there are some kinks in this part of the logic - system installs of libs on Windows is a relatively uncommon build scenario, and not one I'm well set up to test.

Jeffrey Liu (Aug 20 2021 at 17:04):

starseeker (Aug 20 2021 at 17:09):

@Jeffrey Liu I pushed an update to the zlib and png logic - when you get a chance if you can try from a clean build directory and see if that works it would be helpful :-)

Jeffrey Liu (Aug 20 2021 at 17:22):

Ugh, still an error with ZLib - looks like the include directory isn't actually being set properly. Will pull the changes and try a fresh build.

Jeffrey Liu (Aug 20 2021 at 17:34):

Jeffrey Liu (Aug 20 2021 at 17:41):

I keep getting this error, even though I'm setting ZLIB_ROOT?

424>C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\brlcad\src\other\openNURBS\opennurbs_zlib.h(42,10): fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory

Jeffrey Liu (Aug 20 2021 at 17:42):

ZLIB_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: ZLIB_LIBRARY_DEBUG
ZLIB_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: ZLIB_LIBRARY_RELEASE
ZLIB_LIBRARY_RELEASE-ADVANCED:INTERNAL=1```

Jeffrey Liu (Aug 20 2021 at 17:43):

Also just a note, these compilation errors are being caused when trying to build appleseed with this command:

cmake .. -DAppleseed_ROOT="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed" -DBRLCAD_PNG=SYSTEM -DBRLCAD_ZLIB=SYSTEM -DZLIB_ROOT="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed\windows-deps\stage\vc141\zlib-debug" -DPNG_ROOT="C:\Users\JeffL\Desktop\Open-Source\BRL-CAD\appleseed\windows-deps\stage\vc141\libpng-debug" -DCMAKE_BUILD_TYPE=Debug

Jeffrey Liu (Aug 20 2021 at 18:12):

ZLIB_INCLUDE_DIR:PATH=C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/zlib-debug/include
ZLIB_INCLUDE_DIRS:STRING=C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/zlib-debug/include
ZLIB_LIBRARIES:STRING=C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/zlib-debug/lib/zlibd.lib
ZLIB_LIBRARY_DEBUG:FILEPATH=C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/zlib-debug/lib/zlibd.lib
ZLIB_LIBRARY_RELEASE:FILEPATH=ZLIB_LIBRARY_RELEASE-NOTFOUND

Jeffrey Liu (Aug 20 2021 at 18:18):

starseeker (Aug 20 2021 at 19:38):

starseeker (Aug 20 2021 at 19:41):

You can check what the openNURBS part of the build is seeing by putting the following in src/other/openNURBS/CMakeLists.txt:

message("ZLIB_INCLUDE_DIRS: ${ZLIB_INCLUDE_DIRS}")

Jeffrey Liu (Aug 20 2021 at 19:43):

Yeah, I can definitely see it through the file explorer. I think the issue is also occurring in other projects aside from openNURBs too though.

starseeker (Aug 20 2021 at 19:44):

Can you check the visual studio project to make sure it does in fact have the include directory set?

Jeffrey Liu (Aug 20 2021 at 19:50):

This is what it says, but I'm pretty sure most CMake projects end up doing this:
$(VC_IncludePath);$(WindowsSDK_IncludePath);

starseeker (Aug 20 2021 at 19:59):

starseeker (Aug 20 2021 at 20:03):

fwiw, I just tried pointing my Linux build to appleseed and it did find it and build (crashes at runtime, but does appear to try and do something...)

starseeker (Aug 20 2021 at 20:06):

The ZLIB_INCLUDE_DIRS above looks OK, assuming the file zlib.h is in fact present in appleseed/windows-deps/stage/vc141/zlib-debug/include

Jeffrey Liu (Aug 20 2021 at 20:17):

Jeffrey Liu (Aug 20 2021 at 20:21):

Yeah, printing the include directory also works:

OPENNURBS: ZLIB_INCLUDE_DIRS: C:/Users/JeffL/Desktop/Open-Source/BRL-CAD/appleseed/windows-deps/stage/vc141/zlib-debug/include

Jeffrey Liu (Aug 20 2021 at 20:26):

This is so weird, I can even open zlib.h perfectly fine through VS2019, when trying to jump to it through openNURBS_zlib.h. I'm trying to recompile again but my hopes aren't high.

Jeffrey Liu (Aug 20 2021 at 20:40):

My guess is, even though some projects don't depend on Zlib, including OpenNURBS adds an inherent dependency because opennurbs.h includes opennurbs_zlib.h itself.

Jeffrey Liu (Aug 20 2021 at 20:41):

Jeffrey Liu (Aug 20 2021 at 21:45):

Tried to cheat and add ${ZLIB_INCLUDE_DIRS} to the ${OPENNURBS_INCLUDE_DIRS} definition, but it didn't seem to work. I'm not sure how to find a workaround for this...

starseeker (Aug 21 2021 at 11:24):

Sean (Aug 24 2021 at 05:34):

According to the docs, that's the correct behavior for "if (defined VAR)" as it says that takes no regard to the value, unlike if (VAR) that will consider NOTFOUND as false. Was it supposed to be "if (VAR)"?

Sean (Nov 02 2021 at 15:57):

Sean (Dec 02 2021 at 17:06):

Jeffrey Liu (Dec 03 2021 at 19:49):

Sean (Dec 05 2021 at 05:19):

@Jeffrey Liu YES! The biggest is probably that it now walks the hierarchy and registers each region individually with appleseed.

Sean (Dec 05 2021 at 05:20):

that required creating a bounding box callback in the plugin so each object would report its box correctly (pre-computed on the art side)

Sean (Dec 05 2021 at 05:21):

another big change was getting shaders working, so you can specify an OSL shader, specify per-object colors, etc.. that took some doing. there's even a path (still not fully hooked up, but looks like it'll work) for going from materialx shaders to osl shaders.

Sean (Dec 05 2021 at 05:22):

chris also got a handful of rt's command-line options working including the az/el options for setting the view, background color, the set command, the number of samples to use

Jeffrey Liu (Dec 05 2021 at 21:04):

that's so cool! those were like the main few things on to-do list right? I'll try to read through the commits on the pull request to catch up on things

Jeffrey Liu (Dec 15 2021 at 20:45):

@Sean I'll be on winter break after my last final in a few days - is there anything I can contribute to the appleseed project at the moment? I was originally planning on completing stuff from the to-do list on the wiki, but it seems like a lot of that has already been completed.

starseeker (Dec 21 2021 at 01:52):

@Jeffrey Liu Unless Sean chimes in, you might want to take a look at the process of translating to/from Y up and Z up coordinate systems. From what I was told, there are still some issues lurking in that part of the logic.

starseeker (Dec 21 2021 at 01:52):

Jeffrey Liu (Dec 21 2021 at 05:46):

Got it, thanks - I'll try taking some time to set it up after the new year and see if I can contribute anything.

Jeffrey Liu (Jan 05 2022 at 04:41):

Just chiming in again, in case there's anything I can do: is this where I can find the most updated version of the progress so far? https://github.com/BRL-CAD/brlcad/pull/11. I just wanted to make sure if this was the right place to look.

Sean (Jan 08 2022 at 06:48):

@Jeffrey Liu the latest is actually mixed in that PR and another bigger monster PR. I need to pull them out, but working on multithreading should be pretty isolated if you want to give that a go... that would be awesome!

Jeffrey Liu (Jan 08 2022 at 08:04):

Sean (Mar 12 2022 at 19:30):

Sean (Mar 12 2022 at 19:31):

@Jeffrey Liu I'm merging the monster patch today finally, so should be good to go. I also updated the wiki page with status since several of the big items were resolved.

Jeffrey Liu (Mar 13 2022 at 21:05):

Awesome, I'll try to check it out and recompile this week. Do you know if any student has shown interest in this project for GSoC 2022?

Sean (Mar 15 2022 at 14:55):

@Jeffrey Liu none so far, but we do have a team of students in Texas working on it. there's also an appleseed project someone could propose or work on that would greatly help: https://github.com/opencax/GSoC/issues/64

Sean (Mar 15 2022 at 14:56):

If nobody proposes it, we'll likely have to do at least parts of that so we can do release builds..

Sean (Mar 22 2022 at 22:33):

Sean (Apr 29 2022 at 02:44):

Sean (Apr 29 2022 at 12:01):

Sean (Apr 30 2022 at 19:40):

Sean (Feb 22 2023 at 06:26):

starseeker (Sep 14 2023 at 12:42):

Does anybody happen to know if BRL-CAD's use of Appleseed still requires Embree? Or can we skip that dependency since we're using our ray intersections?

Sean (Sep 14 2023 at 13:25):

Needs it. It’s been a while since I looked but I believe it’s still using embree for the highest level spatial partitioning and traversal until it encounters a BRL-CAD entity. You also could have non BRL-CAD entities in the scene.

starseeker (Sep 14 2023 at 13:45):

starseeker (Sep 14 2023 at 13:47):

@Sean are the updates to Appleseed that are pending upstream submission anywhere I can access? I don't want to jinx myself but on Linux I've managed to build the newest versions of the dependencies listed at https://github.com/appleseedhq/linux-deps/releases so I'm curious to try building Appleseed proper.

starseeker (Sep 14 2023 at 13:49):

I still need to handle flex/bison, which apparently are needed by OSL, and do a systematic check to see if I've inadvertently pulled in system libs anywhere I shouldn't (not to mention actually testing if any of the built stuff actually works...)

starseeker (Sep 14 2023 at 13:50):

And "mean" doesn't even begin to describe what a full build of all of this looks like - it's a 17 gig build directory even without Appleseed proper (hi LLVM...)

starseeker (Sep 14 2023 at 13:53):

(Don't worry, I'm doing all this in a fork of brlcad_externals - I'm not moving that one beyond the existing set until we get things tied off for switching over.)

Sean (Sep 14 2023 at 14:01):

Some of it is that some of it isn’t. There’s a pull request and get hub that has most of the python changes but some of the cmake changes I just have locally as I wasn’t trying to be clean. I don’t think the student was able to figure it out but then you can probably figure it out faster than he did, some of the dependencies changed name and their variables changed others split to separate things so variables need to get updated. I think Boost needed a couple flags.

Sean (Sep 14 2023 at 14:03):

There’s also a pending pull request with a bunch of Mac changes, or at least there was. One of the guys might have pulled that one in.

starseeker (Sep 14 2023 at 14:04):

Got it. OK, I'll try to at least rough out the logic for flex/bison and then give it a go - thanks!

Sean (Sep 14 2023 at 14:10):

Sounds good. I’d like to push back a few clean and easy unambiguous pull requests to hopefully earn some direct commit trust. There’s not been an ounce of pushback but it’d be nice to help more directly and not have to sync.

starseeker (Sep 14 2023 at 14:12):

I hadn't looked in a while - the upstream has been really quite since 2020. Not too surprising if you look at the lead dev's day job since then I guess...

Sean (Sep 14 2023 at 14:14):

Yeah I talked to Franz in private a few time since then. Pandemic casualty like many other open source projects. He just has zero time.

Sean (Sep 14 2023 at 14:16):

There’s about four other guys that are basically either active as needed (that is, they will respond and act) or in maintenance mode.

starseeker (Sep 14 2023 at 14:17):

For patch/pull request purposes (or maintaining our own fork in a worst case scenario) should I make a BRL-CAD/appleseed fork? Or would you prefer I keep it in my own project space for now?

Sean (Sep 14 2023 at 14:20):

Their activity, notwithstanding, wouldn’t want to give me impression that we’re trying to take over the project. I think whatever makes it easier for us to make and provide clean patches, that is what we should probably do. I don’t know if that means a fork or your own space for now, but probably the latter? I think the immediate goal would be to get direct permit to help inspire their project activity.

Sean (Sep 14 2023 at 14:21):

starseeker (Sep 14 2023 at 14:21):

<nod> I figured my own space was better, but I didn't want to leave anybody else out in the cold if they wanted to jump in

Sean (Sep 14 2023 at 14:25):

I think that’s fine I mean that’s part of the reason for doing it as pull requests so that any collaboration or discussion happens over in their space.. If they don’t see that activity or don’t get involved, then we will end up with a likely fork, and I don’t think that would be a good thing.

starseeker (Sep 14 2023 at 14:25):

Sean (Sep 14 2023 at 14:28):

Just in case, you’re not tracking, that’s a graph, Kronos announced a new API for configurable rendering systems, configurable raytracing. That may be a future direction if things get too complicated with appleseed, but for now it’s my favorite course because it’s working.

Sean (Sep 14 2023 at 14:30):

Sorry, text to speech is being just lovely. “That’s a graph “ should’ve said at Siggraph

starseeker (Sep 14 2023 at 14:30):

Sean (Sep 14 2023 at 14:35):

Yeah, one of them is basically based off of Intel ospray, quite a few changes since our integration, and in some other ways, but they’ve been involved. It’s a standard that other renderers are adopting so in theory we could do librt rendering in another renderer .

starseeker (Sep 14 2023 at 14:35):

Hmm. Sounds interesting. Is our existing OSPray work potentially reusable in that context?

Sean (Sep 14 2023 at 14:36):

starseeker (Sep 14 2023 at 14:36):

Sean (Sep 14 2023 at 14:39):

I mean it’s roughly useful sure. But some significant changes for sure. We have direct hooks in ospray, embree, and Ispc to make that work.

starseeker (Sep 14 2023 at 14:39):

Sean (Sep 14 2023 at 14:42):

More render mods that are needed as ispc source code, but yeah. Tight optimizations.

starseeker (Sep 14 2023 at 15:13):

As long as I'm at it, I should probably see if I can get OSPray building in this setup as well.

Sean (Sep 14 2023 at 15:50):

starseeker (Sep 14 2023 at 16:01):

Sean (Sep 14 2023 at 16:09):

starseeker (Sep 14 2023 at 16:10):

starseeker (Sep 14 2023 at 23:25):

OK, so good news and bad news. Good news is I finally got ISPC to compile on Linux. The bad news is they apparently have a hard requirement for GNU m4 during build - I tried one of the BSD m4 implementations and it couldn't handle their m4. I also confirmed with the ISPC project they have no interest in m4 portability - they use Cygwin's bundled m4.

starseeker (Sep 14 2023 at 23:26):

Porting GNU m4 to Windows... I supposed I can do it in the end if absolutely necessary, but that's looking to be a non-trivial exercise - and it's GPL to boot.

starseeker (Sep 15 2023 at 22:24):

Yikes. They also require Python. And of course that doesn't install cleanly even on Linux... grr.

starseeker (Sep 15 2023 at 22:35):

It cuts against the grain, but maybe the practical thing to do is require an install of Python3 to build the OSPray stack

starseeker (Sep 15 2023 at 22:36):

starseeker (Sep 15 2023 at 23:43):

starseeker (Sep 18 2023 at 15:34):

starseeker (Sep 20 2023 at 06:38):

Perhaps I'm missing something obvious: when trying to use a bundled icu and xerces-c, I'm getting the following error:

./bin/art
./bin/art: symbol lookup error: /home/user/brlcad/build/lib/libxerces-c-3.2.so: undefined symbol: UCNV_FROM_U_CALLBACK_SUBSTITUTE_73

$ ldd lib/libxerces-c-3.2.so
    linux-vdso.so.1 (0x00007fff109f1000)
    libicuuc.so.73 => /home/user/brlcad/build/lib/libicuuc.so.73 (0x00007f212c406000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f212c000000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f212ce14000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f212cdf0000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f212bc00000)
    libicudata.so.73 => /home/user/brlcad/build/lib/libicudata.so.73 (0x00007f212cde5000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f212cf20000)

$ nm -D /home/user/brlcad/build/lib/libicuuc.so |grep UCNV_FROM_U_CALLBACK_SUBSTITUTE_73
00000000000de680 T UCNV_FROM_U_CALLBACK_SUBSTITUTE_73
$ nm -D /home/user/brlcad/build/lib/libxerces-c-3.2.so |grep UCNV_FROM_U_CALLBACK_SUBSTITUTE_73
                 U UCNV_FROM_U_CALLBACK_SUBSTITUTE_73

starseeker (Sep 21 2023 at 01:35):

starseeker (Sep 21 2023 at 01:36):

starseeker (Sep 22 2023 at 00:38):

Sean (Jan 23 2024 at 15:29):

starseeker (Apr 15 2024 at 17:46):

Hey Sean, out of curiosity do you know how the OpenMoonRay renderer from DreamWorks compares to Appleseed?

Sean (Apr 17 2024 at 17:03):

@starseeker heh, that's like asking how NX compares with Solidworks... They're both production renderers. OpenMoonRay is certainly newer and with lots of really cool features. However, the critical feature Appleseed provided was the hook that allows for the ray intersection query to be replaced with librt. There has been a lot of standardization from Khronos to try and make that a thing all renderers provide, but I've not yet explored how much work that would entail.

starseeker (Apr 17 2024 at 17:44):

@Sean Fair enough. I suppose since OpenMoonRay was asking for help with a Windows port it wouldn't buy us much practically speaking anyway at this point, even if we could plug librt into it as-is...

Sean (Apr 17 2024 at 17:53):

I mean I definitely had the same thought -- gave a nice talk last year at Kronos BoF last year siggraph.

Sean (Apr 17 2024 at 17:54):

Wasn't the only code in discussion too. There's a couple others that might give us production plug-in rendering via librt if the standardization sticks and is adopted. But it was all being announced, so little to go on just yet.

starseeker (Apr 17 2024 at 17:58):

Gotcha. I know a fair chunk of the dependency stack will be the same regardless thanks to everybody using that VFX Platform set, so if it does make sense someday most of the painful part will probably already be handled. I know at this point hunting down our Appleseed Windows issues almost has to be less work than any other option, but I'm a little leery of how quiet the Appleseed upstream is...

Sean (May 21 2024 at 17:12):

Himanshu (Jun 05 2024 at 20:55):

@Sean which version of appleseed can help for art? Currently I pulled the latest one 2.1.0-beta and tried to compile art and VS complaining for #include "foundation/containers/dictionary.h" not found. I saw that this containers/dictionary.h is not present inside appleseed.

Himanshu (Jun 05 2024 at 21:02):

log/consolelogtarget.h" and utility/searchpaths.h is also not present appleseed/include/foundation.

Himanshu (Jun 05 2024 at 21:03):

Himanshu (Jun 05 2024 at 21:04):

starseeker (Jun 06 2024 at 01:39):

Himanshu (Jun 07 2024 at 20:24):

Himanshu (Jun 07 2024 at 21:07):

Himanshu (Jun 07 2024 at 21:08):

Sean (Jun 07 2024 at 21:09):

I tested both the last stable build (from a couple years ago) and a recent dev build and got both to work.

Sean (Jun 07 2024 at 21:10):

Most recently used 2022 so that should be fine. Bigger issue was dependencies, making sure to match the compile settings.

Himanshu (Jun 07 2024 at 21:13):

Himanshu (Jun 07 2024 at 21:22):

Is this step Edit Boost_* component variables to have 'lib' prefix (e.g., libboost_atomic... instead of boost_atomic...) is still required mentioned in readme?

Himanshu (Jun 07 2024 at 21:22):

Sean (Jun 07 2024 at 21:26):

Yeah I think I tried the beta too but there are even more recent builds on Discord

Sean (Jun 07 2024 at 21:27):

I do believe the boost mods are required for all the versions, it’s a cmake issue.

Sean (Jun 07 2024 at 21:27):

Himanshu (Jun 07 2024 at 21:29):

I extracted the beta and I saw the errors that I am getting is for missing files.
image.png

Himanshu (Jun 07 2024 at 21:29):

Done that. And I find boost too there but those variables names of boost I'm not able to edit it. Only values I can edit I see.

Sean (Jun 07 2024 at 21:30):

Himanshu (Jun 07 2024 at 21:31):

Himanshu (Jun 07 2024 at 21:32):

Sean (Jun 07 2024 at 21:32):

Yeah so then don’t bother with the beta. I think I manually added the missing headers but that was a long time ago

Himanshu (Jun 07 2024 at 21:33):

Himanshu (Jun 07 2024 at 22:10):

Wow I am shocked that I downloaded a latest one from their discord channel and those files which are missing now present inside.

Himanshu (Jun 07 2024 at 22:10):

Sean (Jun 07 2024 at 22:21):

Yeah give that a try first. The trick is finding the same boost that they compiled with

Sean (Jun 07 2024 at 22:22):

Himanshu (Jun 08 2024 at 19:44):

Christopher (Jun 08 2024 at 19:50):

It can’t find the bundled appleseed oso shader (as_plastic). art.exe needs to be able to find it in one of the paths in the line that reads “Setting osl shader search paths to..”

Himanshu (Jun 08 2024 at 19:52):

Himanshu (Jun 08 2024 at 19:53):

Himanshu (Jun 08 2024 at 20:24):

Himanshu (Jun 08 2024 at 20:26):

Christopher (Jun 08 2024 at 20:27):

I haven’t poked in the appleseed binary in a while, but they should be. In example shaders or something of the sort

Himanshu (Jun 08 2024 at 20:29):

Himanshu (Jun 08 2024 at 20:30):

Himanshu (Jun 08 2024 at 20:31):

Christopher (Jun 08 2024 at 20:31):

Quick / dirty check would be to copy it over into your brl-cad debug bin/output/shaders and see if it can find it

Himanshu (Jun 08 2024 at 20:35):

Yeah, now it is able to find that as_plastic.so but new shader is missing as_closure2surface.oso

Himanshu (Jun 08 2024 at 20:38):

Christopher (Jun 08 2024 at 20:38):

Himanshu (Jun 08 2024 at 20:39):

Christopher (Jun 08 2024 at 20:39):

There’s a sampling knob you can turn somewhere. Let me see if I can hunt up the magic to do it

Himanshu (Jun 08 2024 at 20:41):

Btw when I given path for appleseed_ROOT, other two variables include and lib didn't recognize the path after I hit configure. So manually I have given the path to both two.
image.png

Christopher (Jun 08 2024 at 20:44):

Christopher (Jun 08 2024 at 20:45):

looks like default samples is 25. Keep in mind, the more samples the longer the render time

Himanshu (Jun 08 2024 at 20:46):

Himanshu (Jun 08 2024 at 20:48):

I ran the command and I didn't see any spike in performance in task manager for both cpu and gpu. I ran that command using 100 samples.

Christopher (Jun 08 2024 at 20:51):

Did you see the upped samples improve the image? It’s possible that command isn’t the correct foo.
If it did, moss world is pretty trivial, it may need a lot of work to notice a spike in the task manager

Christopher (Jun 08 2024 at 20:52):

Himanshu (Jun 08 2024 at 20:52):

Himanshu (Jun 08 2024 at 20:53):

Christopher (Jun 08 2024 at 20:54):

Himanshu (Jun 08 2024 at 20:54):

Himanshu (Jun 08 2024 at 20:56):

Himanshu (Jun 08 2024 at 20:57):

Sean (Jun 12 2024 at 19:33):

I don't think you need the headers at that point. It possibly affects the compilation of new shaders as that is done on the fly.

Sean (Jun 12 2024 at 19:33):

Most concerning quality-wise is the lighting setup it still not decent. It's too dark by default. I think it's just using default hard-coded value right now.

Himanshu (Jun 14 2024 at 12:24):

Did I miss something during cmake part? Because after I compiled art and ran it, it's complaining for OSL headers.

Himanshu (Jun 14 2024 at 13:00):

@Sean Where I should start looking for the files? Because the goal here will be to make art read and work with any OSL or MaterialX shader networks, including ones using texturing, emission, subsurface scattering, etc. applied to BRL-CAD geometry.

Christopher (Jun 14 2024 at 13:33):

art is relying on precompiled osl shaders (.oso). The first step would be to get appleseed to recognize the need, and compile .osl on demand. There is already skeleton code tying in MaterialX, so the jump after supporting osl compilation should be pretty straight forward

Sean (Jun 14 2024 at 15:11):

I remember seeing code for compiling .osl files on the fly, but definitely not seeing it in there now...

Sean (Jun 14 2024 at 15:12):

there's just one mention in region registration that the form for uncompiled osl's is different.

Sean (Jun 14 2024 at 15:13):

It may be something that Appleseed does automatically -- I'd check the code to asr:: Shader_Group to see what they do -- could very well be automatic if the headers and such are found properly.

Himanshu (Jun 14 2024 at 20:18):

Himanshu (Jun 14 2024 at 20:21):

Himanshu (Jun 14 2024 at 20:47):

Initially I have set Appleseed_ROOT but still after one time configure it shows it can't find include and libs of appleseed:
image.png
image.png

Himanshu (Jun 15 2024 at 07:21):

Oh I see now. I just copied shaders dir from appleseed to brlcad_appleseed so that art can find all those .oso file that is required for rendering.

Himanshu (Jun 15 2024 at 07:23):

Is there any way I can see objects of a .g file using art so that I can pass that object instead of all.g?

Himanshu (Jun 15 2024 at 07:27):

Sean (Jun 18 2024 at 20:52):

Sean (Jun 18 2024 at 20:53):

It just happens to be named all.g for moss.g but could be named anything. You can run ls instead of tops to see all objects or search / to print a hierarchical listing, etc.

Sean (Jun 18 2024 at 20:54):

If you have at rt command working you should be able to replace it with art to get the same rendering using Appleseed optics instead of rt’s, if that wasn’t obvious also.

starseeker (Jun 26 2024 at 23:34):

Sigh. Well, the good news is I got virtually all the dependencies updated, make check passes, and I got art to compile on Ubuntu with the latest LLVM 18 and OSL 1.3.10.0. The bad news is all I get is a black silhouette of moss in the output image, and I don't have a clue what's wrong.

starseeker (Jun 26 2024 at 23:39):

Sean (Jun 27 2024 at 05:45):

Might help to check the OSL release notes. I'd guess some default light value / variable was introduced that is initialized to zero. The fact that you get a silhouette implies the ray tracing itself is just fine, but does point at OSL update introducing some change.

Himanshu (Jun 29 2024 at 14:55):

Sean (Jun 29 2024 at 15:45):

That looks pretty good. Can you see if you can figure out why it’s so dark and washed out? It might be a setting automatically being written to the project in art.cpp probably wherever it’s setting that blue background.

Sean (Jun 29 2024 at 15:47):

With rt, we have a notion of default environment ambient lighting. For art, we probably need to make a global light source that is tied to the default ambient value so it’s both brighter by default but also can be made brighter or darker based on the -A value.

Sean (Jun 29 2024 at 15:51):

Lights are one thing that hasn’t been implemented yet because someone will need to figure out a way to map lights or specify lighting via shaders the way Appleseed does it. Our existing light settings are liboptical so they don’t have to be preserved or used, but if would be convenient if they did map to something.

Sean (Jun 29 2024 at 15:51):

An example of that is in moss where there is a little light sphere right in the middle of the model.

Himanshu (Jun 29 2024 at 15:56):

Himanshu (Jun 30 2024 at 10:14):

@Sean Here what I found light_intensity *= AmbientIntensity; in line 253 of art.cpp, I guess light_intensity determines how bright the light source is and AmbientIntensity is a general light that affects all objects in the scene equally.

Himanshu (Jun 30 2024 at 10:14):

Himanshu (Jun 30 2024 at 10:50):

Himanshu (Jun 30 2024 at 11:13):

Himanshu (Jul 02 2024 at 23:47):

Sean (Jul 02 2024 at 23:47):

Sean (Jul 02 2024 at 23:48):

Note that AmbientIntensity in rt (and presumably art, but maybe not) is controlled via the existing -A option, so you can specify -A1 for example

Himanshu (Jul 02 2024 at 23:56):

Himanshu (Jul 02 2024 at 23:57):

Himanshu (Jul 03 2024 at 00:03):

Christopher (Jul 03 2024 at 04:44):

the color is coming from the bishop model. You could use the 'mater' command (something like "mater bishop.r . 0 255 0 .") would set the bishop green, for example

Himanshu (Jul 03 2024 at 23:20):

Himanshu (Jul 03 2024 at 23:25):

@Christopher I am confused little bit for what is shader? I know shader is like a program that runs in gpu. So here shaders have different meaning?

Himanshu (Jul 03 2024 at 23:27):

Himanshu (Jul 04 2024 at 00:02):

I am wondering now if entire graphics pipeline is written in C++ like Vulkan then what does shaders play a role in graphics pipeline?

Sean (Jul 04 2024 at 00:57):

A shader is a bit of logic that gives geometry appearance. Does not have to involve a gpu as it is a general concept with many kinds of implementations. Imagine you have an empty window or image and I tell you which pixels have geometry. Shaders are the bit of logic that colors the pixels.

Sean (Jul 04 2024 at 01:02):

A classic shader taught in intro graphics classes is the phong shader. You can read the wiki page but the basic idea is to consider the color and angle of the surface for a given hit point and that gives a nice simplified appearance of the surface curvature. With a couple other inputs, you can make things appear shiny, flat, transparent, etc with very little code and very few parameters.

Sean (Jul 04 2024 at 01:08):

For production rendering, you typically do not use gpu shaders like glsl for various reasons. In BRL-CAD there is liboptical shaders (see src/liboptical) which is what rt uses and there are shaders supported by appleseed which includes their own old-style shaders like rt’s as well as a newer general production rendering shader framework called Open Shading Language or OSL shaders for more advanced rendering. Art creates an OSL shader definition automatically when loading and preparing geometry for rendering.

Himanshu (Jul 08 2024 at 20:59):

@Sean So deafult value of AmbientIntensity is set to 0.4. light_intensity *= ambient_intensity scales light intensity based on the ambient intensity. This is why scene looks darker when the ambient intensity is 0.4 and brighter when it is 1.0.

Himanshu (Jul 08 2024 at 21:01):

Himanshu (Jul 08 2024 at 21:06):

my question is why the default value is 0.4 when we know we will be getting darker image . Why not always 1.0? Or it will depend on light intensity always?

Christopher (Jul 08 2024 at 22:11):

I don't think there is any specific reason 0.4 was settled on. In well defined scenes, with multiple light sources, too high of a value will white-wash the image. And, as you've seen with a single light source in the example models, too low a value will make it darker. Somewhere in the middle gives flexibility from render to render.

Himanshu (Jul 08 2024 at 22:17):

So to start with I should do this "The first step would be to get appleseed to recognize the need, and compile .osl on demand." So where I should look at? I mean code files.

Sean (Jul 08 2024 at 22:30):

With rt, we don't necessarily get a darker image as the default lighting has been calibrated for ambient+direct so that you typically see something when you render, and it's typically not too bright and not too dark.

As for why that value -- I can only speculate as it's always been 0.4 for rt. That value goes all the way back to 1989 and wasn't documented. Now that said, the intention of the value is the contribution of ambient light to the rendering equation, and the 0.4 means 40% of the illumination is from ambient and 60% is coming from direct lighting.

There are default direct lights in rt that are automatically created -- I don't believe we create the same default direct lights in art, so we're only/mostly seeing the contribution from the ambient parameter.

Sean (Jul 08 2024 at 22:34):

BUT they're also entirely different light spaces with different rendering approaches so getting rt and art to roughly match using the same value was probably wishful thinking. What's really needed is to calibrate the intensity of a test image with controlled light conditions against an identical render environment.

That would be like creating a simple sphere on a black background, rendering with rt, calculating the average intensity at 0.4 and a couple other values like A=0.0 through A=2.0 in 0.1 increments. The default lights rt creates would need to be created in art as well, or eliminate the default light in rt and compare with a similar light definition with art, make art's background also black, then calibrate the AmbientIntensity value across that same sepectrum to produce the same intensity from art.

Christopher (Jul 08 2024 at 22:55):

That will hinge largely on building and bundling appleseed with BRL-CAD. The pipeline is in place with 'bext', but building appleseed, OSL, and the rest of the dependency stack is still very fragile. That is actively being worked on by starseeker and myself.

It may be an easier starting point, since you're also getting familiar with the lighting system, to look at translating BRL-CAD designated light sources into appleseed light sources.

Christopher (Jul 08 2024 at 22:57):

Right now, only one point light is being generated with each scene (src/art/art.cpp ~733). Ideally, this would not only be a hard coded light source but would use BRL-CAD material shaders designated as lights and create them

Sean (Jul 08 2024 at 23:14):

Yeah, Rt creates three lights by default that are auto positioned for a given scene being rendered. Art needs to do that and ideally support custom lights too.

Himanshu (Jul 08 2024 at 23:22):

Is there any specific thing like deciding how many lights will be there in a scene? Like art now have only one light. So the number of lights in a scene can be decided through a user I guess? So what I came to know up to now is that BRL-CAD material shaders can be designated to define lights. This means that instead of hard-coding light sources, we can use material shaders within BRL-CAD to specify lighting properties.

Himanshu (Jul 08 2024 at 23:25):

So ambient intensity, light intensity, light color and light position value will be extracted from the shaders I guess?

Sean (Jul 10 2024 at 05:51):

What I was going to say is that in Rt, there are different lighting modes (see src/rt/view.c header comments) where it creates either one or three default lights (see light_maker() in src/liboptical/sh_light.c) depending on the lighting mode UNLESS there are explicit lights in the scene (e.g., moss.g's all.g scene has a light).

The default for as long as I can remember is supposed to be 3 lights, but I just now noticed that it appears another dev changed the default back to just one light back in 2004. So looks like current is just one light at the eye.

Sean (Jul 10 2024 at 05:53):

Sean (Jul 11 2024 at 20:23):

Now I kind of want to revisit whether we can restore 3-light as a brighter default. Will have to run a slew of tests to see if I can get at the blooming issues Lee encountered, how prevalent and if they can be overcome.

Sean (Jul 13 2024 at 16:35):

It's both -- even with PBR, you have some notion of global light and users need to be able to configure what that light is like. In rt, we just have the -A ambient knob, -l lighting model type, and a default automatic light. If the user creates lights manually, the default light is disabled and it just uses what they specified (so they get that light plus the -A ambient light). In those manually specified lights, they can control light intensity, color, and position as classical/old/liboptical shader settings.

With art, it's kind of the same situation with there needing to be default automatic light(s), possibly some ambient light separately, and definitely explicit lights defined via new/pbr/osl shaders.

Himanshu (Jul 17 2024 at 15:25):

left one havoc have three lights compared to right one where it only contain one light?

Himanshu (Jul 17 2024 at 15:35):

Himanshu (Jul 17 2024 at 15:40):

Himanshu (Jul 17 2024 at 15:42):

Where I can find disney principled shader so that I can test it too? Also what do you mean by hard-wired to single-file shaders?

Christopher (Jul 17 2024 at 16:03):

art is using a default plastic osl shader with color mapping. logic around 395-510 in src/art/art.cpp

Himanshu (Jul 17 2024 at 16:09):

Himanshu (Jul 17 2024 at 16:10):

Christopher (Jul 17 2024 at 16:12):

Yes, that is the eventual goal. There is a rough mechanism through the 'material' command that will use the shader if it can find it (art.cpp: lines 400-415), but that will need to get much more user friendly.

Himanshu (Oct 31 2024 at 19:19):

I am again going to compile art. At that time, idk what I downloaded for boost but now I saw that there are multiple .exe files here https://sourceforge.net/projects/boost/files/boost-binaries/1.70.0/. Usually 64 bit is the way to go but I saw MSVC 14.0 to 14.2. What should I take from here?

Sean (Nov 01 2024 at 15:27):

@Himanshu I don't think it mattered last time I checked, but you want to use that one that matches your msvc -- 14.2 is 2019, 14.0 is 2015

Sean (Nov 01 2024 at 15:27):

bigger question is 1.70 vs 1.69, but you might just have to try both. They have different cmake settings if memory serves, so it's a little tricky to get it right.

Sean (Nov 01 2024 at 15:28):

Longer-term, we want to eliminate boost as it's a source of frustration and complexity.

Sean (Nov 01 2024 at 15:28):

so that's totally something that would be helpful to work on (eliminating boost).

Himanshu (Nov 01 2024 at 17:55):

Sean (Nov 01 2024 at 17:56):

Yeah probably the c++17 stl or other smaller libs or even custom code. Boost isn’t used in a lot of places.

Stream: brlcad

Topic: Appleseed

Rahil Malik (Jan 07 2018 at 20:00):

Rahil Malik (Jan 07 2018 at 20:02):

Rahil Malik (Jan 07 2018 at 20:10):

Mahdi (Jan 07 2018 at 20:11):

Rahil Malik (Jan 07 2018 at 20:11):

Mahdi (Jan 07 2018 at 20:12):

Rahil Malik (Jan 07 2018 at 20:14):

Rahil Malik (Jan 07 2018 at 20:14):

Sean (Jan 07 2018 at 20:15):

Rahil Malik (Jan 07 2018 at 20:16):

Rahil Malik (Jan 07 2018 at 20:16):

Sean (Jan 07 2018 at 20:17):

Sean (Jan 07 2018 at 20:17):

Sean (Jan 07 2018 at 20:17):

Sean (Jan 07 2018 at 20:17):

Rahil Malik (Jan 07 2018 at 20:18):

Rahil Malik (Jan 07 2018 at 20:19):

Rahil Malik (Jan 07 2018 at 20:21):

Sean (Jan 07 2018 at 20:31):

Sean (Jan 07 2018 at 20:32):

Rahil Malik (Jan 07 2018 at 20:34):

Rahil Malik (Jan 07 2018 at 20:34):

Rahil Malik (Jan 07 2018 at 20:35):

Mahdi (Jan 07 2018 at 20:36):

Sean (Jan 07 2018 at 20:39):

Sean (Jan 07 2018 at 20:39):

Sean (Jan 07 2018 at 20:39):

Sean (Jan 07 2018 at 20:40):

Mahdi (Jan 07 2018 at 20:44):

Sean (Jan 07 2018 at 20:45):

Sean (Jan 07 2018 at 20:45):

caleb parks (Jan 07 2018 at 20:50):

Mahdi (Jan 07 2018 at 20:51):

Rahil Malik (Jan 08 2018 at 00:56):

Mahdi (Jan 08 2018 at 01:33):

Rahil Malik (Jan 08 2018 at 02:29):

Rahil Malik (Jan 08 2018 at 02:30):

Sean (Jan 08 2018 at 03:18):

Rahil Malik (Jan 08 2018 at 03:22):

Sean (Jan 08 2018 at 03:23):

Sean (Jan 08 2018 at 03:23):

Rahil Malik (Jan 08 2018 at 03:23):

Sean (Jan 08 2018 at 03:24):

Rahil Malik (Jan 08 2018 at 03:24):

Sean (Jan 08 2018 at 03:24):

Rahil Malik (Jan 08 2018 at 03:25):

Sean (Jan 08 2018 at 03:25):

Rahil Malik (Jan 08 2018 at 03:25):

Sean (Jan 08 2018 at 03:26):

Rahil Malik (Jan 08 2018 at 03:26):

Sean (Jan 08 2018 at 03:26):

Rahil Malik (Jan 08 2018 at 03:27):

Sean (Jan 08 2018 at 03:27):

Rahil Malik (Jan 08 2018 at 03:28):

Rahil Malik (Jan 08 2018 at 03:29):

Rahil Malik (Jan 08 2018 at 03:30):

Sean (Jan 08 2018 at 03:32):

Sean (Jan 08 2018 at 03:32):

Sean (Jan 08 2018 at 03:32):

Sean (Jan 08 2018 at 03:33):

Rahil Malik (Jan 08 2018 at 03:33):

Sean (Jan 08 2018 at 03:33):

Sean (Jan 08 2018 at 03:34):

Sean (Jan 08 2018 at 03:34):

Rahil Malik (Jan 08 2018 at 03:34):

Rahil Malik (Jan 08 2018 at 03:34):

Sean (Jan 08 2018 at 03:35):

Rahil Malik (Jan 08 2018 at 03:36):

Rahil Malik (Jan 08 2018 at 03:36):

Sean (Jan 08 2018 at 03:36):

Rahil Malik (Jan 08 2018 at 03:37):

Rahil Malik (Jan 08 2018 at 03:37):

Rahil Malik (Jan 08 2018 at 03:38):

Sean (Jan 19 2018 at 05:17):

Mitesh (Jan 19 2018 at 07:56):

Jeff Sieu (Jan 19 2018 at 08:02):

Jeff Sieu (Jan 19 2018 at 08:02):

Jeff Sieu (Jan 19 2018 at 08:04):