Re: [brlcad-devel] GSoC 2022

[Daniel Roßberg]

Hello Vasco,

There was a similar question on the GSoC mailing list recently:
https://groups.google.com/g/google-summer-of-code-discuss/c/B4XFJIJ__gA/m/JHGoRYWtBAAJ
If you can't access the link, the answer was "Correct, you are not
eligible to be a GSoC contributor in 2022 if you were a GSoC student
back in 2019."

I don't want to keep you from working on the OpenCL port, but I'm
afraid that you can't do this as a GSoC contributor.

Regards,
Daniel

Am So., 27. März 2022 um 04:32 Uhr schrieb Vasco Costa :
>
> Hello,
> I am interested in continuing work to finish the main bottlenecks in the 
> BRL-CAD OpenCL port.
> These would be, I think, NURBS, plate triangles, and Pipe primitives render 
> support.
>
> I already participated in GSoC as a student once several years back. So this 
> would be my second time.
>
> From what I understand I do not be enrolled as a student to participate this 
> year. But what is this that you need to be a newbie to open source? If you 
> can apply two times for GSoC, how can you even even apply a second time at 
> all? You won't be a newbie to open source then right?
>
> Regards,
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel


___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Release preparations commencing

[Daniel Roßberg]

Compilation works with the current CMake version.

Regards,
Daniel

Am Do., 11. Feb. 2021 um 11:48 Uhr schrieb Daniel Roßberg <
danielmrossb...@gmail.com>:

> Confirmed.
>
> The set_property() statements are a bit different in this CMakeLists.txt
> file: APPEND vs. APPEND_STRING
> "If the APPEND option is given the list is appended to any existing
> property value (except that empty values are ignored and not appended). If
> the APPEND_STRING option is given the string is appended to any existing
> property value as string, i.e. it results in a longer string and not a list
> of strings."
>
> However, I'll try again with current CMake binaries.
>
> Regards,
> Daniel
>
> Am Mi., 10. Feb. 2021 um 16:46 Uhr schrieb Clifford Yapp <
> cliffy...@gmail.com>:
>
>> So, to confirm you're seeing the line:
>>
>> 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD
>> 7.32.2/share/man"-Ot -Oi
>>
>> Checking my output, it looks like:
>>
>> 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD
>> 7.32.2/share/man";-Ot -Oi
>>
>> Those flags are coming from this line (src/other/tcl/CMakeLists.txt:115):
>>
>> set_property(SOURCE ${srcfile} APPEND_STRING PROPERTY COMPILE_DEFINITIONS
>> "-Ot -Oi -fp:strict -Gs -GS -GL -MD")
>>
>> My first suggestion would be to try a newer CMake version and see if that
>> addresses it.
>>
>> Cliff
>>
>> On Wed, Feb 10, 2021 at 5:32 AM Daniel Roßberg 
>> wrote:
>>
>>> Yes, clean checkout and new created build directory. CMake version is
>>> 3.15.4.
>>>
>>> The bug is visible in the tcl.vcxproj file: In the lines containing
>>> CFG_RUNTIME_DOCDIR, a semicolon is missing after the directory string. If
>>> you have it with your version, I'll try again with an updated CMake.
>>> (Unfortunately, it can happen that I can't update it before next Monday.)
>>>
>>> Regards,
>>> Daniel
>>>
>>> Am Mi., 10. Feb. 2021 um 00:05 Uhr schrieb Clifford Yapp <
>>> cliffy...@gmail.com>:
>>>
>>>> Is that with a clean build directory?  Also, which version of CMake?
>>>>
>>>> I also built with VS2019, so it's curious that that configuration
>>>> should fail...
>>>>
>>>>
>>>> On Tue, Feb 9, 2021 at 10:44 AM Daniel Roßberg <
>>>> danielmrossb...@gmail.com> wrote:
>>>>
>>>>> Hmm, my Visual Studio 2019 build fails, Release, sources from
>>>>> branches/RELEASE, plain CMake run (nothing changed).
>>>>> Error in src/other/tcl/generic/tclPkgConfig.c, line 107.  The
>>>>> CFG_RUNTIME_DOCDIR makro looks bad.  It includes compiler switches after
>>>>> the path string.  They aren't cleanly separated (at least for Visual
>>>>> Studio).
>>>>>
>>>>> Regards
>>>>> Daniel
>>>>>
>>>>> Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp <
>>>>> cliffy...@gmail.com>:
>>>>>
>>>>>> Release preparations are underway.  Trunk sources merged to the
>>>>>> RELEASE branch will be reviewed for sync to STABLE and release tagging.
>>>>>> Please help test by compiling distcheck-full and running benchmark, mged,
>>>>>> and archer.
>>>>>> ___
>>>>>> BRL-CAD Developer mailing list
>>>>>> brlcad-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>>>>
>>>>> ___
>>>>> BRL-CAD Developer mailing list
>>>>> brlcad-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>>>
>>>> ___
>>>> BRL-CAD Developer mailing list
>>>> brlcad-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>>
>>> ___
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Release preparations commencing

[Daniel Roßberg]

Confirmed.

The set_property() statements are a bit different in this CMakeLists.txt
file: APPEND vs. APPEND_STRING
"If the APPEND option is given the list is appended to any existing
property value (except that empty values are ignored and not appended). If
the APPEND_STRING option is given the string is appended to any existing
property value as string, i.e. it results in a longer string and not a list
of strings."

However, I'll try again with current CMake binaries.

Regards,
Daniel

Am Mi., 10. Feb. 2021 um 16:46 Uhr schrieb Clifford Yapp <
cliffy...@gmail.com>:

> So, to confirm you're seeing the line:
>
> 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD
> 7.32.2/share/man"-Ot -Oi
>
> Checking my output, it looks like:
>
> 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD
> 7.32.2/share/man";-Ot -Oi
>
> Those flags are coming from this line (src/other/tcl/CMakeLists.txt:115):
>
> set_property(SOURCE ${srcfile} APPEND_STRING PROPERTY COMPILE_DEFINITIONS
> "-Ot -Oi -fp:strict -Gs -GS -GL -MD")
>
> My first suggestion would be to try a newer CMake version and see if that
> addresses it.
>
> Cliff
>
> On Wed, Feb 10, 2021 at 5:32 AM Daniel Roßberg 
> wrote:
>
>> Yes, clean checkout and new created build directory. CMake version is
>> 3.15.4.
>>
>> The bug is visible in the tcl.vcxproj file: In the lines containing
>> CFG_RUNTIME_DOCDIR, a semicolon is missing after the directory string. If
>> you have it with your version, I'll try again with an updated CMake.
>> (Unfortunately, it can happen that I can't update it before next Monday.)
>>
>> Regards,
>> Daniel
>>
>> Am Mi., 10. Feb. 2021 um 00:05 Uhr schrieb Clifford Yapp <
>> cliffy...@gmail.com>:
>>
>>> Is that with a clean build directory?  Also, which version of CMake?
>>>
>>> I also built with VS2019, so it's curious that that configuration should
>>> fail...
>>>
>>>
>>> On Tue, Feb 9, 2021 at 10:44 AM Daniel Roßberg <
>>> danielmrossb...@gmail.com> wrote:
>>>
>>>> Hmm, my Visual Studio 2019 build fails, Release, sources from
>>>> branches/RELEASE, plain CMake run (nothing changed).
>>>> Error in src/other/tcl/generic/tclPkgConfig.c, line 107.  The
>>>> CFG_RUNTIME_DOCDIR makro looks bad.  It includes compiler switches after
>>>> the path string.  They aren't cleanly separated (at least for Visual
>>>> Studio).
>>>>
>>>> Regards
>>>> Daniel
>>>>
>>>> Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp <
>>>> cliffy...@gmail.com>:
>>>>
>>>>> Release preparations are underway.  Trunk sources merged to the
>>>>> RELEASE branch will be reviewed for sync to STABLE and release tagging.
>>>>> Please help test by compiling distcheck-full and running benchmark, mged,
>>>>> and archer.
>>>>> ___
>>>>> BRL-CAD Developer mailing list
>>>>> brlcad-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>>>
>>>> ___
>>>> BRL-CAD Developer mailing list
>>>> brlcad-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>>
>>> ___
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Release preparations commencing

[Daniel Roßberg]

Yes, clean checkout and new created build directory. CMake version is
3.15.4.

The bug is visible in the tcl.vcxproj file: In the lines containing
CFG_RUNTIME_DOCDIR, a semicolon is missing after the directory string. If
you have it with your version, I'll try again with an updated CMake.
(Unfortunately, it can happen that I can't update it before next Monday.)

Regards,
Daniel

Am Mi., 10. Feb. 2021 um 00:05 Uhr schrieb Clifford Yapp <
cliffy...@gmail.com>:

> Is that with a clean build directory?  Also, which version of CMake?
>
> I also built with VS2019, so it's curious that that configuration should
> fail...
>
>
> On Tue, Feb 9, 2021 at 10:44 AM Daniel Roßberg 
> wrote:
>
>> Hmm, my Visual Studio 2019 build fails, Release, sources from
>> branches/RELEASE, plain CMake run (nothing changed).
>> Error in src/other/tcl/generic/tclPkgConfig.c, line 107.  The
>> CFG_RUNTIME_DOCDIR makro looks bad.  It includes compiler switches after
>> the path string.  They aren't cleanly separated (at least for Visual
>> Studio).
>>
>> Regards
>> Daniel
>>
>> Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp <
>> cliffy...@gmail.com>:
>>
>>> Release preparations are underway.  Trunk sources merged to the RELEASE
>>> branch will be reviewed for sync to STABLE and release tagging.  Please
>>> help test by compiling distcheck-full and running benchmark, mged, and
>>> archer.
>>> ___
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Release preparations commencing

[Daniel Roßberg]

Hmm, my Visual Studio 2019 build fails, Release, sources from
branches/RELEASE, plain CMake run (nothing changed).
Error in src/other/tcl/generic/tclPkgConfig.c, line 107.  The
CFG_RUNTIME_DOCDIR makro looks bad.  It includes compiler switches after
the path string.  They aren't cleanly separated (at least for Visual
Studio).

Regards
Daniel

Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp :

> Release preparations are underway.  Trunk sources merged to the RELEASE
> branch will be reviewed for sync to STABLE and release tagging.  Please
> help test by compiling distcheck-full and running benchmark, mged, and
> archer.
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Nested TCL in mged

[Daniel Roßberg]

I can edit "Support Requests", "Feature Requests", "Geometry", and
"Patches", but not "Bugs". And, if I try to hack it in the URL, I get a
"Forbidden" page. Maybe, the bugs are not part of the general tickets group?

Regards,
Daniel

Am Fr., 22. Jan. 2021 um 21:38 Uhr schrieb Christopher Sean Morrison via
brlcad-devel :

>
>
> On Jan 22, 2021, at 3:03 AM, Daniel Roßberg 
> wrote:
>
> These posts (mailing list and bug tracker) were made in parallel, and the
> issue is solved. Unfortunately, I cannot edit the bug report to change its
> status.
>
>
> Were you perhaps not logged in?  You should be able to edit status (you
> have to click the edit icon in the top-right).  I just checked permissions
> and it does say anyone in the Developer group should be able to edit any
> ticket.  We only have the one group.  You’re definitely in the Developer
> group…  :)
>
> Cheers!
> Sean
>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Nested TCL in mged

[Daniel Roßberg]

These posts (mailing list and bug tracker) were made in parallel, and the
issue is solved. Unfortunately, I cannot edit the bug report to change its
status.

Thanks,
Daniel

Am Fr., 22. Jan. 2021 um 08:51 Uhr schrieb Christopher Sean Morrison via
brlcad-devel :

>
> Was the post before you found the cause or are you asking why it throws an
> error on the set command with glob_compat_mode / "special characters"
> handling turned on?  Whether or not a database is loaded doesn’t/shouldn’t
> affect whether glob_compat_mode is set (and doesn’t appear to for me).
>
> With globbing on, that set command will match against a db object
> containing a single char of ‘l’, ‘i’, ’s’, ’t’, ‘p’, ‘1’, ‘2’, ‘ ‘, and
> maybe ‘$’…  which of course isn’t likely to match so it’s equivalent to
> “set l1” without any args, resulting in  an error message.  If there does
> happen to be a db with a single-char object matching, then one will of
> course get different behavior when that database is loaded vs loaded (i.e.,
> single char list vs error).
>
> Cheers!
> Sean
>
>
> On Jan 22, 2021, at 2:13 AM, Daniel Roßberg 
> wrote:
>
> Hi Sean,
>
> Yep, see https://sourceforge.net/p/brlcad/bugs/393/. It's the "Special
> Characters" setting.
>
> Regards,
> Daniel
>
> Am Do., 21. Jan. 2021 um 22:22 Uhr schrieb Christopher Sean Morrison via
> brlcad-devel :
>
>>
>>
>> On Jan 20, 2021, at 2:54 AM, Daniel Roßberg 
>> wrote:
>>
>> Why does the following code behave differently in mged, depending on if a
>> database is loaded or not:
>>
>> set P1 "0 0"
>> set P2 "1 1"
>> set L1 [list $P1 $P2]
>>
>>
>> What do you mean?  I get "{0 0} {1 1}" regardless of opening a database
>> or not, which is what I’d expect and matches what tclsh reports:
>>
>> mged> set glob_compat_mode 0
>> 0
>> mged> set p1 "0 0"
>> 0 0
>> mged> set p2 "1 1"
>> 1 1
>> mged> set l1 [list $p1 $p2]
>> {0 0} {1 1}
>> mged> puts $l1
>> {0 0} {1 1}
>>
>> agua:~ morrison$ tclsh
>> % set p1 "0 0"
>> 0 0
>> % set p2 "1 1"
>> 1 1
>> % set l1 [list $p1 $p2]
>> {0 0} {1 1}
>> % echo $l1
>> {0 0} {1 1}
>>
>> Are you seeing something different?
>>
>> Cheers!
>> Sean
>>
>>
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GSoC: Creation of NURBS

[Daniel Roßberg]

Hi,

Yes, sure, but, let's stay with the creation of NURBS entities for the
moment. It is very unsatisfactory that this can only be done with he help
of external programs.

OpenVSP is a good reference. It's about Design Cockpit 43, a somehow
similar application (before somebody asks: I've never touched or even seen
this software, I try to help somebody who has the task to export the
geometry to BRL-CAD). DC43 is written in Java, and it was decided that it's
the best to write a text file which can be parsed with mged. This seems to
work for almost all primitives, beside twisted lofts.

The idea with the scripting resulted from laziness: I consider it as easier
to wrap the C++ by a scripting language than to invent an ASCII .3dm file
format. However, the final decision (scripting or ASCII 3DM, which
scripting language, swig yes or no) could be made part of the student's
proposal.

Regards,
Daniel

Am Di., 19. Jan. 2021 um 19:50 Uhr schrieb Christopher Sean Morrison via
brlcad-devel :

> Hi Daniel,
>
> Yes, import via 3dm-g or step-g are the two main methods.  They can also
> be created directly with openNURBS — there are several source code examples
> in src/proc-db (see the C++ files).
>
> Lua is good stuff and obviously really easy to integrate.. but there has
> also been good progress made on a direct python interface too.  That code
> currently resides in a repo fork, but was last worked on by Jaipal in 2018
> — he’s got a nice article up at
> https://medium.com/@Mr_Jaypee/brl-cads-python-procedural-geometry-990e3c286a63
>  and
> the code is on github.
>
> I don’t think python or lua as a new required dep are a problem at all.
> I’ve had a goal for years to have a built-in procedural primitive where one
> can describe geometry and define behavior with code (starting with either
> tcl, lua, python, or pure “ged” command listings).  Orthogonal to creating
> NURBS entities of course..
>
> Cheers!
> Sean
>
>
> On Jan 19, 2021, at 1:39 PM, Daniel Roßberg 
> wrote:
>
> Hello all,
>
> I was recently asked, how to create a NURBS solid in BRL-CAD.
> Unfortunately, I didn't know another possibility than importing them from
> Rhino. It should however be possible to create them with openNURBS
> functionality.
>
> My idea is to wrap the openNURBS classes by the Lua scripting language.
> Because of its compactness, it would be possible to bundle it with BRL-CAD
> and have it accessible from mged.
>
> It should also be mentioned that there is already a Python scripting
> interface with the rhino3dm interface. But, making this standard for
> BRL-CAD would bloat the program a bit, or?
>
> What do you think?
>
> Regards,
> Daniel
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Nested TCL in mged

[Daniel Roßberg]

Why does the following code behave differently in mged, depending on if a
database is loaded or not:

set P1 "0 0"
set P2 "1 1"
set L1 [list $P1 $P2]

Regards,
Daniel
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] GSoC: Creation of NURBS

[Daniel Roßberg]

Hello all,

I was recently asked, how to create a NURBS solid in BRL-CAD.
Unfortunately, I didn't know another possibility than importing them from
Rhino. It should however be possible to create them with openNURBS
functionality.

My idea is to wrap the openNURBS classes by the Lua scripting language.
Because of its compactness, it would be possible to bundle it with BRL-CAD
and have it accessible from mged.

It should also be mentioned that there is already a Python scripting
interface with the rhino3dm interface. But, making this standard for
BRL-CAD would bloat the program a bit, or?

What do you think?

Regards,
Daniel
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] BRL-CAD compiling questions

[Daniel Roßberg]

I don't know much about IRIX, but I would expect the libraries to be
installed in /usr/lib(?)

BRLCAD_BUNDLED_LIBS is a flag which can be AUTO, BUNDLED, or SYSTEM.  And,
CMake should automatically detect the installed libs if it is set to AUTO.
If this detection fails because of an unusual installation directory of the
libraries, you can add the directory to the SRC_OTHER_ADDED_DIRS CMake
variable.

I don't know which versions of the XML tools will work and which won't.
What is currently used in BRL-CAD is libexslt version 0.8.15, libxml
version 2.7.8, and libxslt version1.1.26.  However, you should give your
functional ports a try.

Regards,
Daniel

Am Do., 19. März 2020 um 23:21 Uhr schrieb Xavier Nye :

> Hello, sorry for the late reply.
>
> About compiling BRL-CAD on IRIX, you said that I could use my own versions
> of libxml. Would you possibly know what the minimum supported version of
> libxml/libxslt/libexslt would be? This would be helpful as we may already
> have a functional port.
>
> Also, where are the pre-built versions of these libraries supposed to be
> installed? Am I supposed to set BRLCAD_BUNDLED_LIBS equal to the path where
> I installed these? Could you please clarify this a bit?
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------
> *From:* Daniel Roßberg 
> *Sent:* Wednesday, February 12, 2020 11:21:22 AM
> *To:* BRL-CAD Developer Mailing List 
> *Subject:* Re: [brlcad-devel] BRL-CAD compiling questions
>
> Hello Xavier,
>
>
> Currently I am trying to compile the latest release of BRL-CAD (7.28.0) on
> IRIX. I have a couple of questions about the compilation process and
> hopefully the answers can help me to get it to build
>
> - Currently the main problems I seem to have with getting it to build come
> from libxml. Is it possible to disable the XML module from compiling? The
> cmake file seems to suggest so but I can't quite tell how.
>
>
> First, check that the CMake variable BRLCAD_BUNDLED_LIBS is at least set
> to AUTO.  Then, install libxml, libexslt, and libxslt (everything which
> is included in the misc/tools/xmltools directory) from wherever it works.
> After this, the build shouldn't touch the xmltools directory any more.
> (Clean up the build directory before your next CMake run.)
>
> The directories included in the BRLCAD_BUNDLED_LIBS build are written to
> the SRC_OTHER_ADDED_DIRS CMake variable.
>
>
> - When cmake runs, it correctly detects the compiled as GCC 9.2 (a port to
> IRIX). However during the build process the build fails due to a compiler
> error. The make files generated by cmake are attempting to use a MIPSPro
> compiler flag (-rdata_shared) even though it detects the compiler as GCC
> 9.2. Would it be better to use something like GCC 4.2 (I think the last GCC
> that supported IRIX) or use MIPSPro?
>
>
> Without having tested it, I'm afraid that gcc 4.2 won't work.  BRL_CAD
> uses some recent C and C++ language features.  However, you could point
> CMake to the IRIX gcc to use this instead and see what happens.
>
> Regards,
> Daniel
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] off_t size mismatch

[Daniel Roßberg]

Currently, it looks like tools like g2asc or glint don't work from a VS2019
release build.  (If __STDC__ is defined or not doesn't matter.)  I think,
this is caused by an implementation detail of the C library in VS2019.
There, sys/stat.h contains an inline function for fstat, which calls a
version for a 32 bit off_t.

The "#define fstat _fstati64" in config_win.h changes this inline function
too.  I.e., this function has now the name _fstati64, but has still the
call to a 32 bit off_t version.  If libbu reads now 64 bit instead of 32 to
get the size, the value is a bit large.


> P.S. - it's probably worth updating rt^3 to the just-tagged 7.30.6, if it
> works - 7.30.4 has a significant bug in the NURBS raytracing.
>
Thanks, will do so.

Regards,
Daniel
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] off_t size mismatch

[Daniel Roßberg]

Okay, thanks Clifford.
What I don't understand is, how the redefinition of off_t helped in this
issue.  The C library should still work with the small size.  On the other
hand, _stati64 is used there, but this redefinition may lead to an infinite
recursion in fstat() (depending on the type/implementation details of the C
library used) ...

At least, I know now where to look.

Thank you,
Daniel


Am Do., 19. März 2020 um 13:02 Uhr schrieb Clifford Yapp <
cliffy...@gmail.com>:

> If I remember correctly, at least some versions of Visual Studio have an
> off_t that is 32 bit even on a 64 bit machine:
>
>
> https://developercommunity.visualstudio.com/content/problem/308714/in-c-header-systypesh-off-t-is-defined-as-32-bit-s.html
>
> The acid test is to go with the default off_t and create a .g file that is
> too large to work with without a 64 bit off_t.  (I don't recall offhand
> which operations fail - I would expect "ls" to since it's supposed to find
> everything.)
>
>
> On Thu, Mar 19, 2020 at 6:15 AM Daniel Roßberg 
> wrote:
>
>> Hi,
>>
>> What's the background behind the OFF_T_SIZE_MISMATCH stuff in common.h?
>> Is this relevant for MS Visual Studio only?
>>
>> I came across this while investigating a strange behavior in VS2019.
>> There I saw different sizes of off_t in BRL-CAD, because of the typedefs
>> there, and the C library, which doesn't know about common.h.
>>
>> For VS2019, it looks like these lines could simply be omitted.
>>
>> Regards,
>> Daniel
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] off_t size mismatch

[Daniel Roßberg]

Hi,

What's the background behind the OFF_T_SIZE_MISMATCH stuff in common.h?  Is
this relevant for MS Visual Studio only?

I came across this while investigating a strange behavior in VS2019.  There
I saw different sizes of off_t in BRL-CAD, because of the typedefs there,
and the C library, which doesn't know about common.h.

For VS2019, it looks like these lines could simply be omitted.

Regards,
Daniel
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Is 32 bit still supported?

[Daniel Roßberg]

I've just fixed it for MS Visual Studio 2019 (revision 75025).
Maybe, you want to test it with Visual Studio 2017.  Clean up your build
directory first.

Regards,
Daniel

Am Fr., 13. März 2020 um 16:22 Uhr schrieb Ngadou Yopa <
yopasylves...@gmail.com>:

> Greetings everyone
>
> I think a great number of people are still running 32 bit OS especially
> back here.
> I suggest it as a GSoC project else I will be willing to work on it these
> months.
>
> Regards
>
> Ngadou Yopa
>
>
> On Wed, 11 Mar 2020 at 17:52, Christopher Sean Morrison via brlcad-devel <
> brlcad-devel@lists.sourceforge.net> wrote:
>
>>
>> On March 11, 2020 at 11:20 AM, Daniel Roßberg 
>> wrote:
>>
>> Hi,
>> I just tried to compile BRL-CAD 7.30.4 with MS Visual Studio 2019 for
>> win32, but got a lot of errors.  Most of them are connected to off_t in
>> vls.  However, are 32 bit platforms still officially supported?
>>
>>
>> If someone is willing to maintain it, sure.
>>
>> It's been a couple years since I've done a 32-bit compile myself, but I
>> would still expect it to still work.  Whether we keep all the right
>> cmake+header defines correct so that it works out of the box ... that's
>> clearly the issue.
>>
>> We have a new Jenkins CI installation in place where we can make sure
>> 32-bit is added to the list of tested configurations.  I would not,
>> however, anticipate us going out of our way given it's no longer common.
>>
>> Cheers!
>> Sean
>>
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Is 32 bit still supported?

[Daniel Roßberg]

Hi,
I just tried to compile BRL-CAD 7.30.4 with MS Visual Studio 2019 for
win32, but got a lot of errors.  Most of them are connected to off_t in
vls.  However, are 32 bit platforms still officially supported?

Regards,
Daniel
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] BRL-CAD compiling questions

[Daniel Roßberg]

Hello Xavier,


> Currently I am trying to compile the latest release of BRL-CAD (7.28.0) on
> IRIX. I have a couple of questions about the compilation process and
> hopefully the answers can help me to get it to build
>
> - Currently the main problems I seem to have with getting it to build come
> from libxml. Is it possible to disable the XML module from compiling? The
> cmake file seems to suggest so but I can't quite tell how.
>

First, check that the CMake variable BRLCAD_BUNDLED_LIBS is at least set to
AUTO.  Then, install libxml, libexslt, and libxslt (everything which
is included in the misc/tools/xmltools directory) from wherever it works.
After this, the build shouldn't touch the xmltools directory any more.
(Clean up the build directory before your next CMake run.)

The directories included in the BRLCAD_BUNDLED_LIBS build are written to
the SRC_OTHER_ADDED_DIRS CMake variable.


> - When cmake runs, it correctly detects the compiled as GCC 9.2 (a port to
> IRIX). However during the build process the build fails due to a compiler
> error. The make files generated by cmake are attempting to use a MIPSPro
> compiler flag (-rdata_shared) even though it detects the compiler as GCC
> 9.2. Would it be better to use something like GCC 4.2 (I think the last GCC
> that supported IRIX) or use MIPSPro?
>

Without having tested it, I'm afraid that gcc 4.2 won't work.  BRL_CAD uses
some recent C and C++ language features.  However, you could point CMake to
the IRIX gcc to use this instead and see what happens.

Regards,
Daniel
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] New Comer To BRL-CAD

[Daniel Roßberg]

Hello Shubham,

Sorry for the late respond. Your mail got somehow lost in the pre-Christmas
fuss, and I found it again only recently.

Nice to her, that you are interested in BRL-CAD. There are two ways you can
start, and you should do both:

1.) Learn about 3D solid modelling with BR-CAD.
If you want to contribute to BRL-CAD, you need to know what it does and
how. You can install the program from a binary package (e.g.
https://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Windows/7.26.0/BRL-CAD_7.26.0.2_x64.exe/download
for Windows), read the documentation on our web site https://brlcad.org/,
and do the tutorial
https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf. You will learn
much about typical BRL-CAD use-cases this way.

2.) Compile the BRL-CAD programs from source code
Prerequisites are Subversion, CMake, and a compiler (Visual Studio for
Windows). You will find more information here:
http://brlcad.org/wiki/Building_from_SVN and here:
https://brlcad.org/wiki/Compiling (for Linux).

Then, you can lookout for small programming tasks. For example, by
understanding and fixing a bug (https://sourceforge.net/p/brlcad/bugs/).

Regards,
Daniel

Am Fr., 20. Dez. 2019 um 15:33 Uhr schrieb Shubham Abhang <
shubhamabhan...@gmail.com>:

> Hello everyone,
> I am Shubham Abhang from India. I am very much interested in geometry.
> That's why I would like to contribute to BRL-CAD. I am good at C, C++. I
> have downloaded brlcad-code repository. But I am not getting where to
> start. Please help me through it.
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GCI mentors

[Daniel Roßberg]

Sreyansh,

You should create an account for our Zulip chat (
https://brlcad.zulipchat.com) too.  We expect many asking students there.

Daniel

Am Fr., 29. Nov. 2019 um 08:59 Uhr schrieb Christopher Sean Morrison via
brlcad-devel :

> Thank you Sreyansh!
>
> You can find task brainstorming for 2017 here:
>   https://brlcad.org/wiki/Google_Code_In/2017/Tasks
> That led to this task list (though not all were used):
>
> https://docs.google.com/spreadsheets/d/1XujqkcBmditFNpBuCQt9CRchXSEhb-SOlvFqW2d6sak/edit?usp=sharing
> You can find the actual lists of tasks used in previous years** here:
>   http://brlcad.org/gci/
>
> The desired focus this year is on work that can be immediately integrated
> (e.g., most design tasks require substantial work afterwards, so not a
> priority this year), so that means more tasks on code, docs, the website,
> etc.
>
> Cheers!
> Sean
>
> ** For example, our 2017 task list was http://brlcad.org/gci/2017/tasks/ and
> submitted work can be seen at http://brlcad.org/gci/data/uncategorized/
>
>
>
> On Nov 29, 2019, at 1:39 AM, Sreyansh Jain 
> wrote:
>
> Hi Sean,
>
> I'd be happy to volunteer as GCI mentor. I was a part of GSoC last year
> with BRL-CAD project. Since this would be my first time, let me go through
> the previous years' tasks, get the gist of it and then I'll add the tasks.
> Hope that helps.
>
> Warm Regards,
>
> *Sreyansh Jain*
>
>
> On Fri, Nov 29, 2019 at 11:03 AM Christopher Sean Morrison via
> brlcad-devel  wrote:
>
>> Hi All,
>>
>> I think I may have said there wouldn’t be another e-mail asking, but we
>> could really use more GCI mentors.  If you’re able to help, especially over
>> the next couple weeks as there’s an initial rush of kids, your help would
>> be greatly appreciated.
>>
>> If you can just write up task ideas, that can help — go to
>> http://brlcad.org/wiki/Google_Code_In/2019/Tasks to brainstorm or send
>> me task writeups via e-mail.
>>
>> Even if you can only help review student submissions 1 day a week, that
>> would help.  Send me an e-mail and I’ll get you set up.
>>
>> If you’re willing to do more, that would be great too of course.
>>
>> GCI is a phenomenal program for interacting with fresh contributors and
>> making changes to BRL-CAD in a very short period of time. We get YEARS of
>> work submitted to us over just a few weeks of the program.  The more
>> mentors we have, the faster we respond to them, the more BRL-CAD and our
>> community benefit.
>>
>> Cheers!
>> Sean
>>
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Introduction

[Daniel Roßberg]

Also about this, there was a chat recently on our Zulip channel.

Regards,
Daniel

Am Do., 14. März 2019 um 18:57 Uhr schrieb Ngadou Yopa <
yopasylves...@gmail.com>:

> Thanks Daniel
>
> I will follow those steps. Actually, i had question on OGV-meteor. I had
> issues building it and at one point, my pc froze (eOS, 6Gb ram, core  i3
> processor). I don't know if my specs are small or i missed something.
>
> Thanks
>
> Ngadou
>
> On Thu, 14 Mar 2019 at 18:09, Daniel Roßberg 
> wrote:
>
>> He didn't asked a question ;)
>>
>> However, to become familiar with BRL-CAD programs, you should install (e.g.
>> from
>> https://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Windows/7.26.0/
>> ) and play with it.  Use
>> https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf for guidance.
>> When you are done with exploring its main features, download the source
>> code (https://brlcad.org/wiki/SVN), compile (
>> https://brlcad.org/wiki/Compiling), and install it.  The main
>> development happens on Linux.  You should have an installation to hand at
>> least for reference.
>>
>> You could work on a project of another program under the BRL-CAD umbrella
>> too. See https://opencax.github.io and
>> https://github.com/opencax/GSoC/issues for these.
>>
>> And, you should visit our Zulip chat at https://brlcad.zulipchat.com as
>> well.  Scroll back there to see what was already said.
>>
>>
>> Regards,
>> Daniel
>>
>> Am Do., 14. März 2019 um 16:06 Uhr schrieb blubee blubeeme <
>> gurenc...@gmail.com>:
>>
>>> Hi Ngadou
>>>
>>> Did anyone reply to your message on the brlcad mailing list.
>>>
>>> Best,
>>> Owen
>>>
>>> On Wed, Mar 13, 2019, 19:12 Ngadou Yopa  wrote:
>>>
>>>> Greetings all
>>>>
>>>>   I am Ngadou Yopa an undergraduate student at the University of Buea,
>>>> Cameroon. I study computer science and i like solving problems.
>>>>
>>>> Thanks
>>>>
>>>> Ngadou
>>>> ___
>>>> BRL-CAD Developer mailing list
>>>> brlcad-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>>
>>> ___
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Introduction

[Daniel Roßberg]

He didn't asked a question ;)

However, to become familiar with BRL-CAD programs, you should install (e.g.
from
https://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Windows/7.26.0/
) and play with it.  Use
https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf for guidance.
When you are done with exploring its main features, download the source
code (https://brlcad.org/wiki/SVN), compile (
https://brlcad.org/wiki/Compiling), and install it.  The main development
happens on Linux.  You should have an installation to hand at least for
reference.

You could work on a project of another program under the BRL-CAD umbrella
too. See https://opencax.github.io and
https://github.com/opencax/GSoC/issues for these.

And, you should visit our Zulip chat at https://brlcad.zulipchat.com as
well.  Scroll back there to see what was already said.


Regards,
Daniel

Am Do., 14. März 2019 um 16:06 Uhr schrieb blubee blubeeme <
gurenc...@gmail.com>:

> Hi Ngadou
>
> Did anyone reply to your message on the brlcad mailing list.
>
> Best,
> Owen
>
> On Wed, Mar 13, 2019, 19:12 Ngadou Yopa  wrote:
>
>> Greetings all
>>
>>   I am Ngadou Yopa an undergraduate student at the University of Buea,
>> Cameroon. I study computer science and i like solving problems.
>>
>> Thanks
>>
>> Ngadou
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] mged with multiple threads

[Daniel Roßberg]

2018-07-04 7:26 GMT+02:00 Christopher Sean Morrison via brlcad-devel <
brlcad-devel@lists.sourceforge.net>:

>
> On Jun 27, 2018, at 12:36 PM, Daniel Roßberg 
> wrote:
>
> Is the Tk-mged supposed to work with multiple threads?  It looks like if a
> simple call to bu_log() in a subthread can crash it.
>
>
> It is supposed to work, but that’s been historically tricky code to get
> right and keep working because of how libbu manages a set of global locks.
> Currently, nearly everything goes through BU_SEM_SYSCALL which means you
> can’t recursively call bu functions from bu functions safely without
> hitting a deadlock, race, or other issue.  This is particularly problematic
> for bu_log() and it’s hook functions (which very often are written to call
> bu functions, but that’s nfg) and bu_malloc() and friends.
>
> What’s needed is breaking up BU_SEM_SYSCALL into different semaphores for
> each of the respective bu groupings that need to coordinate some access.
>

​I'm afraid there is an additional issue with calling Tk functions: In
general, Tk functions have to be called all from the same thread because
they use thread specific memory.  See e.g. this thread: ​
https://sourceforge.net/p/tktoolkit/bugs/1359/

And, this was the reason why we see crashes with
check_overlaps: Tk_FreeGC() calls TkGetDisplay() which looks at thread
specific data, can't find anything there, and returned NULL
which Tk_FreeGC() tries to dereferenciate. According to the above mentioned
discussion, there are specific Tcl/Tk APIs for queuing events from one
thread into another, which would be necessary to use in a multi thread
Tk-mged.


Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] mged with multiple threads

[Daniel Roßberg]

Is the Tk-mged supposed to work with multiple threads?  It looks like if a
simple call to bu_log() in a subthread can crash it.

Archer behaves different.  It doesn't crash, the bu_log() messages go
however to the console.

Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] OpenCL GPGPU Raytracing

[Daniel Roßberg]

Hi Abhishek,

I don't think it's a good idea to make include/rt/geom.h dependent on PCL,
Boost, etc..  You can adapt rt_pnts_internal and the pnt_~ structs to the
needs of PCL but shouldn't include PCL directly.  If there is no other
possibility, you can refer to a PCL structure in rt_pnts_internal or pnt_~
with a void*.
Only librt should be linked with PCL, and there only files contained in
src/librt/primitives/pnts should include it.  To include and use PCL you
had to rename pnts.c to pnts.cpp and make a C++ file from it this way.

Regards,
Daniel

2018-04-07 9:49 GMT+02:00 Abhishek Vasudevan :

> I just switched to Ubuntu for testing out PCL with BRLCAD, because Mac OSX
> just keeps throwing error after error. I was able to build it with PCL in
> the CMakeLists.
>
>  However, when I tried to add PCL libraries in include/rt/geom.h (I was
> trying to replace the pnt structure with that of PCL’s point cloud class),
> I get a build error saying the type ‘namespace' is not found. This is
> because PCL uses the C++ library called Boost and that causes a problem as
> namespaces can’t be used in C programs.
>
> I tried using build option ENABLE_ALL_CXX_COMPILE and still get a
> 'template with C linkage' error.
>  I’m going to try wrapping the C++ functions used by the boost namespace
> to make it work with the header file in C (geom.h) - similar to this
> 
>  answer
> in stack overflow.
>
> Regards,
> Abhishek
>
>
> On Apr 3, 2018, at 2:30 AM, Christopher Sean Morrison 
> wrote:
>
> That build error is in libnetpbm, and it looks like it’s using the Python
> framework, not the python you want to build against.  That’s possibly an
> issue in libnetpbm’s build logic, check the build files there.
>
> Cheers!
> Sean
>
>
> On Apr 2, 2018, at 12:08 PM, Abhishek Vasudevan <
> abhishek.open...@gmail.com> wrote:
>
> Sorry, I think I was using the trunk version. Used the svn command to
> download the code repository. You’re right with the unclean build. I
> cleared up all the build files and tried using 'make install' once again.
> However, this time I’m getting a python related error as shown in the
> screenshot. PCL has some build code related to Python and is somehow
> causing a problem.
>
> PCL works fine when I build it separately, however, throws these errors
> when I try to build it with BRLCAD. Any suggestions on what I should try
> next?
>
> Regards,
> Abhishek
>
> 
>
> On Apr 2, 2018, at 4:40 PM, Christopher Sean Morrison 
> wrote:
>
> No, I don’t.  At quick look, I would think you’ve maybe been trying
> different build settings and this is an “unclean” build.  Try deleting your
> build directory and building again fresh.  If it still doesn’t work, I
> would have said it was something wrong with the Tcl update on trunk last
> week, but you said you’re using 7.26.4 and not trunk — so next suggestion
> would be to try trunk.
>
> Sean
>
>
> On Apr 2, 2018, at 1:54 AM, Abhishek Vasudevan 
> wrote:
>
> I am using the latest version i.e., 7.26.4. I added the following lines to
> the CMakeLists:
>
> find_package(PCL 1.8 REQUIRED COMPONENTS common io)
> include_directories(${PCL_INCLUDE_DIRS})
> link_directories(${PCL_LIBRARY_DIRS})
> add_definitions(${PCL_DEFINITIONS})
>
> After this, I used: cmake .. -DBRLCAD_BUNDLED_LIBS=Bundled
> -DBRLCAD_EXTRADOCS=OFF
> Following this, I used 'sudo make install' and keep getting the error as
> shown in screenshot.
> 
>
> Any idea what this error is about?
>
> Warm regards,
> Abhishek
>
> On Apr 2, 2018, at 12:30 PM, Christopher Sean Morrison 
> wrote:
>
> BRL-CAD 7.2.4 was released in 2005 and didn’t use cmake, so hopefully you
> meant 7.26.4 or, better still, a trunk checkout from the SVN repository.
> If you’re going to be modifying code, you should typically use the latest
> repository sources.
>
> That said, it’s not clear from your screenshot why adding PCL would cause
> an error in xmltools, unless PCL includes its own copy of libxml that is
> incompatible with the bundled xsltproc sources.  Try running cmake with -D
> BRLCAD_EXTRADOCS=OFF
>
> That should turn off the documentation system using xmltools.
>
> Cheers!
> Sean
>
>
>
> On Apr 1, 2018, at 9:46 PM, Abhishek Vasudevan 
> wrote:
>
> Hello,
> I’m having trouble building the code with PCL. I’ve added the PCL
> 'find_package and include_directories’ in the CMakeLists (of the top parent
> directory) and during the build process, it keeps throwing some error
> related to struct _xmlBuf (while scanning the dependencies of target xml in
> file *brlcad-7.2.4/misc/tools/xmltools/libxml/src/HTMLparser.c - *screenshot
> attached). But. when I remove the PCL part from the CMakeLists, the code
> gets built.
>
> I’ll keep trying to resolve this issue. However, it would seem 

Re: [brlcad-devel] Decorator Pattern

[Daniel Roßberg]

You may find an example in the Qt code in rt^3/src/QtGUI.

Regards,
Daniel

2018-03-12 1:33 GMT+01:00 Brad Eric hollister :

> Hi,
>
> I’m preparing a short talk on the decorator pattern for classroom
> instruction.
>
> I’d like to use an example from Brlcad. Are there any such examples in the
> codebase?
>
> Regards,
> Brad
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GSoc 2018

[Daniel Roßberg]

Hi Abhishek,

I'm sure there are many ways you can contribute here.
I've just looked for the first time at our pnts primitive (beside a small
fix for a compiler I made there 9 years ago).  I think this was meant with
"BRL-CAD has a basic point cloud primitive."  And as far as I can see, it
has no real functionality yet.  Especially, the pnts primitive doesn't
describe a 3D solid, which is a problem for a software designed to handle
3D solids.  The pnts primitive sketches currently an idea of how a point
cloud could be handled in BRL-CAD.  E.g., it provides the necessary load
and save functions and the hooks into the mged and archer GUIs.  This
should ease the implementation of the real 3D functionality because you
don't need to struggle with this much any more.

Therefore, if you have an idea of how to bring pnts to live you are
welcome.  Feel free to discuss it here.  Point clouds are often the result
from 3D scans and a matter of visualization which we want to have in
BRL-CAD too.

Regards,
Daniel

2018-03-09 14:14 GMT+01:00 Abhishek Vasudevan :

> Hey guys,
> I am a final year undergrad student from India majoring in Information
> Technology. I am currently in Australia as a research student at the
> University of Melbourne as part of an exchange program. I am working on
> point clouds as part of my research here. I’ve learnt quite a lot about *point
> clouds*, their file formats (PLY, PCD, etc.) and also the Point Cloud
> Library (PCL).
>
> I’ve seen the GSoc ideas page and apparently BRL-CAD has a primitive
> implementation of point clouds. Is there any documentation on how to use
> this in BRL-CAD? Also, what ideas do you have mind in improving the
> performance of your point cloud model?
>
>  I have programmed extensively in C,C++ and Python. Is there any way I can
> make a contribution here?
>
> Warm regards,
> Abhishek
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Parallel build failure

[Daniel Roßberg]

Hi Jonathan,

If I remember correctly, pnglibconf.h will be generated during the CMake
configuration.  The parallel build isn't therefore probable the cause.  You
could try to run cmake from scratch again.  (BTW, do you have any special
CMake settings?)

On the other side, it's possible that version 7.26.4 has some issues -
which the current development version at our repository's trunk hasn't.
Hence, if running cmake again doesn't work I would like to ask you to try
the most recent version.  There we could apply patches if necessary as well.

Regards,
Daniel

2018-02-14 14:23 GMT+01:00 Jonathan Cottrill <
brlcad-de...@jonathancottrill.net>:

> Hello,
>
> I sent this yesterday, but I think it got lost in the SourceForge fiasco.
> If
> not, apologies for the double-post.
>
> When doing a parallel build (make -j8) of 7.26.4, the build fails with the
> following error:
>
> In file included from /brlcad-7.26.4/src/libfb/fb_generic.c:36:0:
> /brlcad-7.26.4/src/other/libpng/png.h:361:27: fatal error: pnglibconf.h:
> No
> such file or directory
>  #   include "pnglibconf.h"
>^
> compilation terminated.
> src/libfb/CMakeFiles/libfb-obj.dir/build.make:86: recipe for target 'src/
> libfb/CMakeFiles/libfb-obj.dir/fb_generic.c.o' failed
> make[2]: *** [src/libfb/CMakeFiles/libfb-obj.dir/fb_generic.c.o] Error 1
> CMakeFiles/Makefile2:8947: recipe for target 'src/libfb/CMakeFiles/libfb-
> obj.dir/all' failed
> make[1]: *** [src/libfb/CMakeFiles/libfb-obj.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
>
> Guessing this is a build-order issue triggered by doing a parallel build?
>
> Thanks,
>
> Jonathan Cottrill
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] WIN32 or _WIN32?

[Daniel Roßberg]

OK, thanks.  However, I don't think I'll have access to a Visual Studio
installation before January 8th again.

Have Happy Holidays,
Daniel

2017-12-22 20:23 GMT+01:00 Christopher Sean Morrison <brl...@mac.com>:

> We should be using the standard one, _WIN32.  Curiously, I thought I
> scrubbed all of the WIN32 ones we were manually defining about a year ago.
>
> Cheers!
> Sean
>
>
> > On Dec 22, 2017, at 8:47 AM, Daniel Roßberg <danielmrossb...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > It looks like that with the current source code revision the Visual
> Studio build is broken, at least on my computer.  In src/libbu/parallel.c
> rt_thread_t isn't defined.  To define it on Windows the WIN32 define has to
> be set, but it isn't.  The predefined macro in a win32 environment is
> _WIN32.  Especially in parallel.c we can find a mixture of both variants.
> Which one is the right one?  Do we want to use the standard (_WIN32) or
> have our own macro (WIN32)?
> >
> > Regards,
> > Daniel
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
> _
> > BRL-CAD Developer mailing list
> > brlcad-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] WIN32 or _WIN32?

[Daniel Roßberg]

Hi,

It looks like that with the current source code revision the Visual Studio
build is broken, at least on my computer.  In src/libbu/parallel.c
rt_thread_t isn't defined.  To define it on Windows the WIN32 define has to
be set, but it isn't.  The predefined macro in a win32 environment is
_WIN32.  Especially in parallel.c we can find a mixture of both variants.
Which one is the right one?  Do we want to use the standard (_WIN32) or
have our own macro (WIN32)?

Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] comparing performance of bu_hash vs C++ map

[Daniel Roßberg]

I've looked into this task for some time and found it difficult to compare
them.   Attached is a version with integers as keys.  I haven't done real
tests with it yet.

Regards
Daniel
//
//  main.cpp
//  test.cpp
//
//  Created by Lucas Prieels on 12/12/17.
//  Copyright © 2017 Lucas Prieels. All rights reserved.
//

#define ll long long

#include "bu.h"
#include "bu/hash.h"
#include 
#include 
#include 

using namespace std;


void addValueBu(bu_hash_tbl* tab, int nbr){
int key = 0;

for (int i=0; i , int nb){
int key = 0;

for (int i=0; i , int nb){
int key = 0;

for (int i=0; i , int nb){
int key = 0;

for (int i=0; i m;
ll int start = bu_gettime();
addValueSTL(m, nb);
ll int time2=bu_gettime();
addAndPopValueSTL(m, nb);
ll int time3=bu_gettime();
addAndRetrieveValueSTL(m, nb);
cout << "Time of execution for STL map: " << endl << "Adding " << nb << " values : " << time2-start << endl << "Adding and popping " << nb << " values : " << time3-time2 << endl << "Adding and retrieving " << nb << " values : " << bu_gettime()-time3 << endl << endl;
}

int main(int ac, char *av[]) {
int nb;
cout << "How many values would you like to test? " << endl;
cin >> nb;
cout << -1;
bu_hash(nb);
stl_map(nb);
return 0;
}
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] The C++11 threading needs some attention

[Daniel Roßberg]

For a simple application as a multithreaded ray-trace the current
implementation seems to work but if a thread creates threads it'll probably
crash again. To make this work the prototype of parallel_mapping() has
probable go to parallel.h (where parallel_cpp11thread() should go to) and
be used in parallel_cpp11thread().  And, the semaphores probably need a fix
too, as already mentioned.

If a GCi student reads this and wants to work on this: Take the "Test and
report on new C++11 parallel threading implementation" task, make sure you
are using C++11 threads, test them (make the program crash ;), or write a
test program (this could be easier to do and to reproduce), and submit your
findings.  Based on this we can create a new task for fixing the bugs.

Daniel

2017-12-15 15:05 GMT+01:00 Christopher Sean Morrison <brl...@mac.com>:

>
> Upon closer inspection, it looks like the semaphore.c changes weren't
> committed which could be messing with the book keeping and thread
> coordination.
>
> Cheers!
> Sean
>
>
> > On Dec 15, 2017, at 3:23 AM, Daniel Roßberg <danielmrossb...@gmail.com>
> wrote:
> >
> > For example, it isn't connected to the parallel_mapping() book-keeping.
> I don't know how bad it is.
> >
> > Regards,
> > Daniel
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
> _
> > BRL-CAD Developer mailing list
> > brlcad-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] The C++11 threading needs some attention

[Daniel Roßberg]

For example, it isn't connected to the parallel_mapping() book-keeping.  I
don't know how bad it is.

Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Zulip for GCI

[Daniel Roßberg]

2017-11-12 21:03 GMT+01:00 Christopher Sean Morrison :

> ...
>
> Only three weeks before GCI begins!  Anyone (GCI mentor or not) is welcome
> to add task ideas here:
> https://brlcad.org/wiki/Google_Code_In/2017/Tasks
>

Only the ideas or the descriptions too? Same format as in Deuces?

Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Organizing tasks and results

[Daniel Roßberg]

The idea was to have the task descriptions in separate files in a format
which easily can be parsed and compiled for upload to Google in some
logical directory structure: brlcad_t-shirt.md for example
Then, for each task there is an issue where it can be discussed with a link
to the file with the description.  Discussions go to the issue and changes
to the description are going to the file.

The task's issues have labels with the state: draft, final, and uploaded.
A new task gets the draft label.  If a task (file) is okey the
corresponding issue has to get the final label.  Then an automatism could
go over all issues with final label, upload the corresponding file contents
to Google and give the issues the uploaded label.  It they are published on
the GCi website too the corresponding issue can be closed.

Then, we are getting the results.  These will be stored along with task
description in a directory structure: .../brlcad_t-shirt/HansDieter for
example.
I find it desirable to have task's descriptions and results close to each
other.  Again, for each result an issue should be created with a link to
the corresponding directory.  Labels could be new, merged, postponed, etc..

To keep track of all these issues a project and cards could be used.

BTW, I wouldn't require the students to send us pull requests because this
would require them to have something we can pull from.  I'm totally fine
with patches.

Regards,
Daniel


2017-11-07 13:44 GMT+01:00 Christopher Sean Morrison :

>
> > Did you had a look at my github attempt?  I tried to utilize issues and
> projects too.
>
> Yes, I did.  This is right in line with what I had in mind.
>
> I don’t know the exact mechanics we want to use yet, but we do probably
> want to keep the completed work separate from the task descriptions.
> Completed tasks may be in the form of a pull request, for example, instead
> of as an issue.  Otherwise, this is in the right direction.  Well want to
> either write our own code or use one of the other org’s scripts for syncing
> task data.
>
> The two main needs we have are 1) some way to semi-automate / manage
> uploading of tasks and 2) a place to retain there work knowing that there’s
> not enough time to review and integrate everything during the contest.
>
> Cheers!
> Sean
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GCI 2017 application submitted

[Daniel Roßberg]

2017-11-07 5:37 GMT+01:00 Christopher Sean Morrison <brl...@mac.com>:

>
> On Nov 4, 2017, at 4:15 PM, Daniel Roßberg <danielmrossb...@gmail.com>
> wrote:
>
> Hmm, I've no experience with working with github.  I suppose that what
> currently can be found at BRL-CAD's and brlcad's repositories doesn't
> reflect what you have in mind.  By this occasion, I played a little bit
> around (https://github.com/drossberg/gci-sandbox).  The downside of
> github is that it's public visible and this isn't recommended before the
> competition has started.
>
>
> Not a major concern.  You can find most org’s GCI tasks publicly
> beforehand; we just tell the students there are no guarantees what will be
> posted (or redirect them towards other activities as I did week before
> last).  You’re right that the current repos don’t reflect what I had in
> mind.
>

Did you had a look at my github attempt?  I tried to utilize issues and
projects too.

Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GCI 2017 application submitted

[Daniel Roßberg]

Hmm, I've no experience with working with github.  I suppose that what
currently can be found at BRL-CAD's and brlcad's repositories doesn't
reflect what you have in mind.  By this occasion, I played a little bit
around (https://github.com/drossberg/gci-sandbox).  The downside of github
is that it's public visible and this isn't recommended before the
competition has started.

Regarding Zulip: I would be nice to have an up to date messenger.  E.g.,
last year I missed the possibility to inform other mentors about the tasks
I was looking at.  Some of them were already reviewed when I wanted to
commit my findings.

Regards,
Daniel

2017-10-24 6:42 GMT+02:00 Christopher Sean Morrison :

> Hi All,
>
> Thanks to all that responded about GCI mentoring!  Our org application has
> been submitted.  Selections get announced in 2 days… and from there orgs
> have approximately a month to prepare our task list.
>
> Towards that end, I propose we either use github issues on a custom repo
> or set up something similar to what the Zulip guys did last year with text
> files and scripts.  You can see their setup here: https://github.com/
> zulip/zulip-gci
>
> Basically, we stub in tasks (either as issues or into repo) and then run
> scripts to upload them into the website.  This same repo can be used for
> submitting pull requests (e.g., QA and design tasks) so submitted completed
> tasks are auto-stashed for later.  Thoughts?
>
> There was some org that had a really nifty demonstration of using issues
> as the tracking mechanism, but I haven’t been able to find it yet.
>
> Cheers!
> Sean
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Heterogeneous densities

[Daniel Roßberg]

spectrum.c was recently removed.  So, update your checked out sources and
check your librt CMakeaLists.txt that it matches with the one on the head
of the reposity (you've probably made changes to it).

Regards,
Daniel

Am 06.10.2017 5:27 nachm. schrieb "Mario Meissner" :

> I am getting compilation errors again, on 70355.
>
> fatal error C1083: Cannot open source file: 'C:\Users\
> MEISSNERBLANCOJOHANN\Desktop\brlcad\trunk2\src\librt\spectrum.c': No such
> file or directory
>
> And indeed no such file exists (I cannot find it anywhere).
>
> Hints? :/
>
> On 4 October 2017 at 23:14, Mario Meissner  wrote:
>
>> So I ended up designing a new algorithm and would love to get some
>> feedback before I implement it.
>> Here it goes:
>>
>> * Sort the points from 'left to right' (distance of projection to inhit)
>> * Look for the closest point to inhit.
>> * Add this point to the list of contributions.
>> * Discard every point 'to the left' of this point.
>> * From the next point onwards, do, for each point:
>> * Take the next point and the last one we added to contributions
>> * Check if the intersection of their middle-plain and the segment
>> lays inside the segment and
>>
>> has no closer point than the two we are using..
>>  * If so, this point's region is crossed by the segment, so we add it to
>> the contribution list.
>>  * If not, then this point's region is not crossed.
>> * Look for the closest point to the outhit.
>> * If this point is the same as the last point we added, finish.
>> * If not, add it and finish.
>>
>> Attached go three pics that are a sample of the example situations I used
>> to develop the algorithm.
>> Ideally, I would need someone to find a situation where this algorithm
>> fails.
>>
>> Thank you in advance,
>> Mario.
>>
>> On 3 October 2017 at 04:14, Christopher Sean Morrison 
>> wrote:
>>
>>>
>>> Hi Mario,
>>>
>>> As always, thank you for all the updates.  Here are some responses to
>>> questions you posted last week.
>>>
>>> I'm passing two arguments to my segment_density, which are inhit and
 outhit points.
 I now realize that these are pointers and could change unexpectedly
 within the call if we run multiple threads.

>>>
>>> The in/out hit point pointers shouldn’t be changing within the call.  I
>>> suspect something else is going on...
>>>
>>>  How can I make this safe? Should I BU_GET safe heap memory to store the
 points for the call, or pass the coordinates one by one as actual numbers?

>>>
>>> In general, the calling code should pass structures to functions (which
>>> can be on the heap or on the stack) and those functions should just fill
>>> them in or read from them (but not both, separate functions for reading and
>>> writing).
>>>
>>> For debugging purposes I would like to set only one thread for rtweight,
>>> how can I do that? The fact that I get 4 or more threads running my
>>> segment_density at the same time makes it difficult to track down issues.
>>>
>>>
>>> Check out rtweight’s manual page (run "brlman rtweight” outside mged),
>>> it’s the -P# option.
>>>
>>> Cheers!
>>> Sean
>>>
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>>>
>>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Google Code In

[Daniel Roßberg]

There would be a lot to do.
First, do we apply as BRL-CAD or OpenCAx?  There was the idea to emphasize
the other projects by using a neutral umbrella.  But, OpenCAx hasn't even a
home page.

Then, we need a landing page for GCi and a way to collect ideas for the
tasks and ideally a way to automatically transfer them to the Google page.
E.g., like https://gitlab.com/librehealth/gci_task_exporter or the one for
Wikimedia (https://github.com/tonythomas01/phabgciscrapbot/
blob/master/crawler.py, https://phabricator.wikimedia.org/project/view/2304/
).

And last but not least, we should prepare a repository to hold the
completed tasks.  They will be deleted from the Google page shortly after
the end of the competition.

Just my 2 ct.
Daniel

2017-10-03 4:01 GMT+02:00 Christopher Sean Morrison :

> We have at least a half dozen mentors, so that sounds like we are good to
> go!  I’ll get started on our application.
>
> Next up would be to sort out what essentials need to happen to make this
> more successful than in previous years.  I have lots of thoughts on some
> changes to make and how to handle tasks, but I’d love to hear what others
> think first.
>
> Cheers!
> Sean
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Heterogeneous densities

[Daniel Roßberg]

Hi Mario,

2017-09-21 18:00 GMT+02:00 Mario Meissner :

> By flag you mean that I should indicate with that variable whether an
> intersection occurred or not?
>

What I meant was: Why has your intersection_t struct an intersect member?
You don't use it.
I wanted to use it as a surrogate for your NULL return value but what was
your reason?


> Also, should I just return it without a pointer, without allocating it on
> the heap? I assume this is what you wanted me to do because you suggested
> my function head to be:
>  struct  intersection_t intersection(point_t p0 
>

I wanted to show you your options because only when you know them you will
be able to make a well reasoned decision.  And, Vasco showed you a third
one.  Now, it's on you to decide (not on me).


> I thought this is not possible because it would be destroyed once the
> function call ends. But apparently it doesn't: https://
> stackoverflow.com/questions/22957175/how-does-function-
> actually-return-struct-variable-in-c
>
> The VS compiler seems to complain when I try to assign the returned struct
> to another variable though.
>

Hmm, I tested it with MSVS 2013.


Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Heterogeneous densities

[Daniel Roßberg]

Hi Mario,

Hmm, it looks like you haven't really understood what I wrote you.  You use
the struct but allocate it with BU_GET() on the heap and don't use its
intersect flag.  But what is really bad is that you don't free it if it
won't be used any more.

BTW, do you have a Chinese OS version?  Your diff files contain Chinese
comments.


Regards,
Daniel


2017-09-21 14:13 GMT+02:00 Mario Meissner <mr.rash@gmail.com>:

> Hi Daniel.
>
> Thank you for your response. Negative values may have been only due to
> using the wrong formatting tag while printing values. I have cleaned up
> some unused variables and fixed the intersection by using your suggestion.
>
> Mass is 0 in the total_weight variable, as if the code wasn't really
> adding up my segment_density values correctly. I might have deleted some
> important code related to the storing or reading of the values. I will
> double check on that now.
> Attached goes current version of my code.
>
> Mario.
>
> On 21 September 2017 at 13:03, Daniel Roßberg <danielmrossb...@gmail.com>
> wrote:
>
>> Hi Mario,
>>
>> I have been trying to track down the reason why some densities are
>>> negative. A few questions I have ended up asking myself:
>>>
>>> - Is it possible for MAGNITUDE() to return a negative number? It would
>>> make no sense to me, but I suspect it's happening.
>>>
>>
>> No, MAGNITUDE() is the square root of a (necessarily)  positive value.
>> You can safely assume it to be not negative.
>>
>> - In my little function intersection I noticed that I am returning a
>>> pointer to a local variable, that could be destroyed in any moment after
>>> the call ends. Instead of that, I want to return a safe variable. How do I
>>> do that in this case?
>>>
>>> I don't understand why it doesn't let me return directly the variable
>>> point_t. It's a pointer, because it's an array, right? As it didn't let me
>>> return the point, I decided to return a pointer to the point instead,
>>> however as I mentioned this is not safe, so I have to change it now. Any
>>> explanation on why I can't return the point, and what I should do to make
>>> it safe?
>>>
>>
>> Well, there is a standard solution for this kind of issue: Putting the
>> data on the heap, e.g.
>> point_t *intersect = (point_t *) bu_malloc(sizeof(point_t),
>> "intersection");
>> with the disadvantage that the caller has explicitly to free the memory
>> with bu_free().
>>
>> It's true that C functions can't return arrays (because of historic
>> reason).  But, returning an array wouldn't help you here as you are using
>> the function's return as a flag for intersection too.  On the other hand,
>> structs can be returned:
>> struct intersection_t {
>> int intersect;
>> point_t intersection_point;
>> };
>>
>> struct  intersection_t intersection(point_t p0, point_t p1, point_t
>> p_co, vect_t p_no) {
>> 
>> should work.
>>
>>
>>> Finally, I think I could need some help regarding the negative values
>>> issue, at least once I'm sure the two points above aren't the cause.
>>>
>>
>> Feel free to ask ;)
>>
>>
>> Regards,
>> Daniel
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Heterogeneous densities

[Daniel Roßberg]

Hi Mario,

I have been trying to track down the reason why some densities are
> negative. A few questions I have ended up asking myself:
>
> - Is it possible for MAGNITUDE() to return a negative number? It would
> make no sense to me, but I suspect it's happening.
>

No, MAGNITUDE() is the square root of a (necessarily)  positive value.  You
can safely assume it to be not negative.

- In my little function intersection I noticed that I am returning a
> pointer to a local variable, that could be destroyed in any moment after
> the call ends. Instead of that, I want to return a safe variable. How do I
> do that in this case?
>
> I don't understand why it doesn't let me return directly the variable
> point_t. It's a pointer, because it's an array, right? As it didn't let me
> return the point, I decided to return a pointer to the point instead,
> however as I mentioned this is not safe, so I have to change it now. Any
> explanation on why I can't return the point, and what I should do to make
> it safe?
>

Well, there is a standard solution for this kind of issue: Putting the data
on the heap, e.g.
point_t *intersect = (point_t *) bu_malloc(sizeof(point_t),
"intersection");
with the disadvantage that the caller has explicitly to free the memory
with bu_free().

It's true that C functions can't return arrays (because of historic
reason).  But, returning an array wouldn't help you here as you are using
the function's return as a flag for intersection too.  On the other hand,
structs can be returned:
struct intersection_t {
int intersect;
point_t intersection_point;
};

struct  intersection_t intersection(point_t p0, point_t p1, point_t
p_co, vect_t p_no) {

should work.


> Finally, I think I could need some help regarding the negative values
> issue, at least once I'm sure the two points above aren't the cause.
>

Feel free to ask ;)


Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Trouble setting up VStudio

[Daniel Roßberg]

Hmm, the error seems to be in librtuif which is on your computer only.
This lib depends e.g. on libbu but this isn't probably mentioned in
librtuif's CMake configuration.

Regards,
Daniel

2017-09-12 23:39 GMT+02:00 Mario Meissner :

> Hello again.
> I'm afraid I ran into more problems while compiling.
> Rtexample works well but not so for rtweight.
> Attached goes my error log.
>
> I ran svn up and build clean before this.
>
> Mario.
>
> On 8 September 2017 at 17:53, Mario Meissner 
> wrote:
>
>> I forgot to reply to this yesterday.
>>
>> r70209 fixed all my problems.
>> Build successful on all platforms (with mingw still installed).
>> Thank you a lot!
>>
>> Mario.
>>
>> On 6 September 2017 at 13:18, Clifford Yapp  wrote:
>>
>>> On Wed, Sep 6, 2017 at 5:58 AM, Mario Meissner 
>>> wrote:
>>> > I noticed that cmake actually links the AWK entry to my mingw
>>> 'gawk.exe'
>>> > file, so I was right with my guess.
>>> >
>>> > After updating to the latest commit available (which is 70194 at the
>>> time of
>>> > writing) i get this cmake error on windows:
>>> >
>>> > CMake Error at CMakeLists.txt:369 (_add_library):
>>> > Cannot find source file:
>>> >
>>> > C:/Users/MEISSNERBLANCOJOHANN/Desktop/brlcad/build/src/other
>>> /libpng/pngprefix.h
>>>
>>> Give r70209 a shot.
>>>
>>> CY
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>>
>>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Heterogeneous densities

[Daniel Roßberg]

Hi Mario,

In 3D space, rectangular to a vector you have a plane and the vector is a
normal vector of this plane.  In this plane are all vectors which are
perpendicular to your first vector, i.e. the vectors which products with
your first vector are 0.  This gives you a first equation with two
variables.

Next, you want to intersect the plane with a ray.  I.e., one vector from
your plan has to be a multiple of the ray which gives you another equation.

However, there should be examples in the BRL-CAD source code for this.
E.g., the ray-trace of the half primitive is very similar to your problem.
There, the intersection of a plane, given by a normal vector and a point in
it, and a ray, given by a start point and a direction, will be computed.

I hope this helps.


Regards,
Daniel



I'm facing a wall. I need to find a perpendicular vector with the condition
that it will intersect a third vector.
Basically, I have the ray and a vector drawn from my current point to the
previous point.
I want the perpendicular bisector of that vector to cross my ray, so that I
can obtain the intersection between the bisector and the ray.

For that I need two things:
1) Obtain the perpendicular vector. in 3D there are infinite options, but
only one will cross the ray. How do I get the one I need?
2) Obtain the intersection point.

I browsed through vmath.h but I didn't find anything that could help me. Do
you know any macro that could be useful here?
Otherwise I will need to make some of my own for this! If so, any ideas on
how to approach it?

Mario.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Trouble setting up VStudio

[Daniel Roßberg]

Hi Mario,

As you may have seen in my previous emails, I moved to Germany on the 1st
of this month.


Interesting.  May I ask in which area of Germany?

I am facing an issue with Visual Studio when I try to build the solution.
For now, and since my laptop is not as quick as my desktop pc was, I want
to build only the rtexample solution.

I downloaded the trunk, ran cmake with VS as a target, loaded the project
and hit Build -> rtexample
Some projects get to compile but there are 5 that throw an error.
Here is the complete log:
https://puu.sh/xqAwb/cf26a811c4.txt

This line might contain part of the solution:
LINK : fatal error LNK1181: cannot open input file
'..\..\Release\lib\libfb.lib'
No such file can be found in that folder.


There is already an error in CMake:
3>Generating pnglibconf.c 3>options.awk: bad line (10): com 3>CMake Error
at scripts/gensrc.cmake:68 (message): 3> Failed to generate pnglibconf.tf5

The other errors seem to be caused by this one.  But, I can't say why
because I've no computer at hand.

Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] [GSoCAx] additional t-shirts

[Daniel Roßberg]

T-shirts size M/female are always welcome.  My daughter likes them.

Regards,
Daniel

Am 01.09.2017 7:32 nachm. schrieb "Christopher Sean Morrison" <
brl...@mac.com>:

> Would anyone like an additional GSoC t-shirt?  Or will be going/presenting
> at an event or have university connection where you might want to give a
> couple t-shirts away?
>
> Cheers!
> Sean
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Summer of CAx" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gsocax+unsubscr...@googlegroups.com.
> To post to this group, send email to gso...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/gsocax/44DF9A98-BFD0-4AE0-933D-C841C882336B%40mac.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations

[Daniel Roßberg]

Hi Shubham,

In your version you multiplied the factor with the matrix entries for every
draw again and again.  This won't work.
However, I committed a solution for the X Window system display manager
which, I think, looks good.

Regards,
Daniel


2017-08-30 8:34 GMT+02:00 Shubham Rathore :

> Hi Daniel,
>
> Thanks for the patch review. I tried the zoom in/out and yes, there is an
> issue with the current scaling. I am curious to know about your approach
> regarding scaling ! Do tell me, if there ain't an issue. :)
>
> Regards,
> Shubham Rathore(:gabbar1947)
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations

[Daniel Roßberg]

Hi Shubham,

Hi Daniel,

Welcome back !


I'm still travelling but I have access to my e-mail and a web browser here
:)

I had a look at your latest patch where I saw two issues:
> - What was your intention for your changes in src/libbn/vlist.c?
>

points related to DISPLAY_MAT not considered as the plane is different. Do
you want it to be removed from the bbox?


The point with the bounding box is that it's given in model coordinates.
Therefore, consider all points which are given in model coordinates for its
computation and exclude all points which are not (e.g. the points which are
in display coordinates).

The point which comes with DISPLAY_MAT is in model coordinates.  It needs
to be used for the determination of the bounding box.  The points which
come with the following LINE_MOVE and LINE_DRAW commands are in display
coordinates.  They have to be excluded from the computation until the next
MODEL_MAT command.

- The expressions with the xmat in the displaymanagers' code have
> unnecessary parenthesis.
>

Done. Meanwhile I made changes to dm-plot as well. I'll upload it in the
next patch.


OK, nice.


Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Annotations

[Daniel Roßberg]

Hi Shubham,

It's nice to see that you are making progress.  I saw the screen shot in
your development log where you plotted the label together with the line.

I had a look at your latest patch where I saw two issues:
- What was your intention for your changes in src/libbn/vlist.c?
- The expressions with the xmat in the displaymanagers' code have
unnecessary parenthesis.


Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Example of heterogeneous density + mass calculation

[Daniel Roßberg]

Hi Mario,

Well, the rt in rtweight comes from ray-trace.  I.e., this program shoots a
series of rays at the model.  The hit() function in src/rt/viewweight.c
determines what shall be done when one of these rays hits a region.

First, it determines the length of the ray inside the region (line 133).
Then, beginning at line 157, it computes the volume which this ray
represents (base on the cell sizes and hypersampling), takes the
line-of-sight into account (which is 100% if the region is fully filled by
the assigned material), and writes the resulting mass into dp->weight.

For heterogeneous regions you need to know exactly where the ray intersect
the region.  These intersection points are ihitp->hit_point
and ohitp->hit_point, I assume.

Hope this helps,
Daniel

2017-07-13 16:45 GMT+02:00 Mario Meissner :

> Hello.
>
> I have calculated the mass of an example of an heterogeneous object using
> a function that defines the density of an object in each point in space,
> and integration to obtain it's mass.
> You can see it here: https://drive.google.com/file/d/
> 0Bz6hfFobLeoyZC1vQ1JwSU05NDg/view
>
> I believe that this model can give support to most types of heterogeneous
> density objects, and can be easily calculated with arbitrary precision by a
> computer. Support for non-continuous densities may also be easy to
> implement alongside this model by using functions with different
> definitions for different regions.
>
> However, as I do not yet understand how rtweight currently behaves, I do
> not know if this model is viable and what other considerations one needs to
> make.
>
> I'll await feedback on this model, and help on understanding the source
> code and current behaviour.
>
> Mario.
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Hi Shubham,

I had a short look at your code.  We talked about it on IRC.  But, as
announced, I haven't the time for a deeper review now.

You should aim for more frequent patch submissions, at least one per
week, for the future.

Regards,
Daniel


2017-06-23 15:31 GMT+02:00 Shubham Rathore :
> Hi Daniel,
>
> I have uploaded the patch. It passes the build and the input part seems to
> work as of now for the text.
>
> I'm sorry, I missed your mail regarding the thursday deadline as it got
> overriden by another mail on the thread on the same day.
>
> I have worked hard on understanding the workflow and to write this code and
> devoted ample time to the project.
>
> I'm left with the onscreen rendering part that I aim to complete in the
> coming days.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Raytracing throws error.

[Daniel Roßberg]

> Following the compilation instructions, the built filesystem on linux
> doesn't yield any Release folder, just a bin folder. That folder contains
> dozens of executables, including mged and archer. However if you look at the
> screenshots I attached, you can see that on windows I do get a release
> folder, however no executables can be found inside the bin of that folder.
> Where are they?

Which target (project) with which configuration (Release/Debug,
win32/x64) did you build?
However, I still recommend to do the installation.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Raytracing throws error.

[Daniel Roßberg]

Hi Mario,

> I'm working my way through the introductory guide, and I haven't been able
> to use raytracing. As I try to do as the guide tells me to, this error shows
> up: http://imgur.com/a/RGCBV , but only after a few minutes of waiting. I'm
> using Arch Linux (Antergos) x64. Am I missing a library? I had to manually
> check for the dependencies, but I might have missed one.

Looks like there is an issue with the frame buffer device.  Maybe this
is helpful: https://wiki.archlinux.org/index.php/Uvesafb

> Also I'd like to ask two secondary questions:
> I tried building for Visual studio as mentioned on a previous post, but the
> resulting build is different from the one I would obtain on linux, as you
> can see here: https://imgur.com/QznornV and https://imgur.com/1YZWULO
> I've not been able to find the archer and mged executables, for example.
> Whats going on here?

They look very much the same.  In case of Linux you have them in the
build/Release/bin directory.  You should look at the same directory
under MS Windows too.

However, I recommend to install the program.  This is "make install"
under Linux and building the INSTALL project under MS Visual Studio.
You can set up the directory where it should put the files with CMake.

> Can I change the color of the console text? I'm using Plasma with a dark
> theme and blue text is difficult to read. The color settings only seem to
> affect the wireframes.

In mged: File -> Preferences -> Color Schemes
Or not?


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

>> - Aim for formal correctness regarding the coding style.  E.g. indents
>> (anno.c line 78 or 1781 et seqq.), consistent number of line feeds
>> between the functions, no trailing spaces.  When your patch is
>> formally correct I can check it in.
>
> Apologies for that! I'll do it as soon as possible.

I'm still waiting for your patch.  Thursday is the last day where I
can review your code before the first evaluations, and patches usually
need some iteration loops before they can be accepted.
Your previous patches looked promising but where incomplete.  I really
would like to see something compiling and working before I let you
pass.  Regarding your development log this should be feasible.  But,
don't wait until the last moment.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Problems while building on Windows

[Daniel Roßberg]

Hi Mario,

I'm not aware of a successful BRL-CAD build with MinGW.  All attempts
I know about got stuck during the CMake configuration, as you did.
What you could do is
- Use MS Visual Studio
- Use Linux in a virtual machine (there is an image among the BRL-CAD downloads)
- Fix BRL-CAD's CMake files (not recommended if you aren't fit in writing them)

Therefore, I'm afraid the answer is negative.


Regards,
Daniel

2017-06-19 12:50 GMT+02:00 Mario Meissner :
> Hello everyone.
> I'm Mario Meissner, I have been elected to work for BRLCAD during the
> summer, in case SOCIS happens. Apparently, they are having administrative
> issues and the start of the coding period has been delayed. Anyway I decided
> to at least set myself up and start on my own.
> I'm trying to set up a Windows working environment, building with the MinGW
> compiler tools and CMake with Eclipse as a target since it's the IDE I have
> currently installed.
>
> Steps I performed:
>
> svn checkout svn://svn.code.sf.net/p/brlcad/code/brlcad/trunk
> brlcad-svn-trunk
>
> Open cmake gui
>
> configure... eclipse cdt4 mingw makefiles, use default native compilers
>
> This is how it looks like: http://i.imgur.com/CMNnICz.png
>
> a long test script runs, and errors occur at the end.
>
> In particular, the errors that seem to break the configuration process are
> the following:
>
> CMake Error at CMakeLists.txt:2738 (file):
>   file failed to open for reading (No such file or directory):
>
> C:/Users/Mario/Desktop/brlcad/bin/CMakeTmp/BRLCAD_BUILD_HOST
>
>
> CMake Error at CMakeLists.txt:2739 (string):
> string sub-command STRIP requires two arguments.
>
>
> I can confirm that there are several files inside cmaketmp, including
> BRLCAD_BUILD_COUNT and BRLCAD_BUILD_USER.
>
> However, no BRLCAD_BUILD_HOST file.
>
> The second error is probably related to the first one. Here is the line that
> fails inside cmakelists:
>
>
> file(READ "${BRLCAD_HOSTNAME_FILE}"  BRLCAD_COMPILE_HOST)
> string(STRIP ${BRLCAD_COMPILE_HOST} BRLCAD_COMPILE_HOST)
> DISTCLEAN("${BRLCAD_HOSTNAME_FILE}")
>
>
> It's surely failing because of the previous error where the file was not
> found.
>
> Here are the trace files it generated, in case you need extra information.
> https://transfer.sh/O32GJ/CMakeOutput.log
> https://transfer.sh/27Qo8/CMakeError.log
> http://i.imgur.com/6ZRiFyu.png
>
> Thank you in advance for helping me out,
> and I apologize for my incompetence.
> Mario.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

> Sir, if you could review the anno.c patch, it would be helpful. I'll rectify
> errors otherwise I'll jump onto the next task.

Some comments after a short review of your patches:
- You created a lot of patch files, one for each source file.  They
are hard to handle, e.g. I had to find or create the corresponding
directories, and incomplete, e.g. the changes to CMakeLists.txt are
missing.  Please, create one patch file containing everything needed.
- You wrote in your log that "annotation" is too long and replaced it
by "anno".  I would name it "annot" because of a possible confusion.
See
http://www.dictionary.com/browse/anno
http://www.dictionary.com/browse/annotation
http://www.dictionary.com/browse/annot
- Aim for formal correctness regarding the coding style.  E.g. indents
(anno.c line 78 or 1781 et seqq.), consistent number of line feeds
between the functions, no trailing spaces.  When your patch is
formally correct I can check it in.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

> Sir, if you could review the anno.c patch, it would be helpful. I'll rectify
> errors otherwise I'll jump onto the next task.

It's on my list for tomorrow, a holiday here.

> Next what I think to do is to implement support for 3D-> 2D, or is there
> something that I'll have to do before it ?

You mean displaying the annotation on top of the model?  You should
definitive work on this.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

The "first input point" part sounds good.

Then we need a list.  You could look at the sketch or pipe how they
are doing it.  We can have multiple texts and lines in any order here.

Regarding the text position, I would use flags, e.g. "bl" or "cc"
which means [t]op, [b]ottom, [l]eft, [r]ight, [c]enter.  (What is
"none"?)

Keep in mind that this is the basic command to create any annotation.
There may be additional convenience functions as (a hypothetical)
"annotate  " which creates a line with predefined length
and angle from the center of the region and puts the text at the end
of it.  But first, you have to create the foundation: The basic
annotation primitive with its command line interface.


Regards,
Daniel

2017-06-13 19:18 GMT+02:00 Shubham Rathore <shubhamrathore1...@gmail.com>:
> Sir,
>
> Regarding the input, what I thought it to be:
>
> static char *p_anno[] = {
> "Enter the point to be annotated: ",
> "Enter Y: ",
> "Enter Z: ",
> "Enter the text label: ",
> "Enter X,Y for the text placement: ",
> "Enter Y: ",
> "Enter the relative vertical position(1->bottom, 2->middle, 3->top,
> 4->none): ",
> "Enter the relative horizontal position(1->right, 2->center, 3->left,
> 4->none): ",
> "Enter the start point for the line segment(X,Y): ",
> "Enter Y: ",
> "Enter the end point for the line segment(X,Y): ",
> "Enter Y: ",
> };
>
>
>
> The First input point can be mapped to the origin in the 2D coordinate
> system.
> This is basically the point which the user wants to annotate.
> The next input points i.e. for the text placement and line segment coords,
> can be entered accordingly.
> I have defined a total of 15 placement flags( refer the latest geom.patch
> update)
> This way it becomes easy for the user to enter the position, which is
> internally appended to find the exact position.
> This way we can fill all the params of the internal object.
> This is currently only for the line segment, which can be extended to
> arc,nurb, beizer etc.
> Next step will be the coordinate plane representation and mapping.
>
> Inputs !
>
> Regards,
> Shubham Rathore(:gabbar1947)
>
> On Mon, Jun 12, 2017 at 2:43 PM, Daniel Roßberg <danielmrossb...@gmail.com>
> wrote:
>>
>> Shubham,
>>
>> > 1) In which file do you think, the placement flag values should be
>> > defined ?
>>
>> include/rt/geom.h
>> Other primitives define their flags there too.
>>
>> > 2) regarding the input. It was decided that the input will be through
>> > the
>> > "in" command:
>> >- in "parameters"
>> >- what all parameters are desired ?
>>
>> The parameters which are needed to fill the rt_anno_internal(?)
>> structure.  The sketch should be a good template for how it should
>> look like for the annotation.
>>
>> > 3) if we talk about line segment , then user can input the point to be
>> > annotated and the coords of the line segment.
>> >  but for beizer, nurb etc. we will need the editor. suggestions please.
>>
>> Again: Similar as for the sketch.  It can be created with an "in" too.
>> The annotation has a parameter "anchor point in 3D space" plus a list
>> of 2D segments.  It should be possible to use a large portion of the
>> sketch code which interprets the TCL input for the annotation.
>>
>> You should aim for getting a line on the screen.  When you are able to
>> see what you are doing it will make the live easier.
>>
>>
>> Regards,
>> Daniel
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

> 1) In which file do you think, the placement flag values should be defined ?

include/rt/geom.h
Other primitives define their flags there too.

> 2) regarding the input. It was decided that the input will be through the
> "in" command:
>- in "parameters"
>- what all parameters are desired ?

The parameters which are needed to fill the rt_anno_internal(?)
structure.  The sketch should be a good template for how it should
look like for the annotation.

> 3) if we talk about line segment , then user can input the point to be
> annotated and the coords of the line segment.
>  but for beizer, nurb etc. we will need the editor. suggestions please.

Again: Similar as for the sketch.  It can be created with an "in" too.
The annotation has a parameter "anchor point in 3D space" plus a list
of 2D segments.  It should be possible to use a large portion of the
sketch code which interprets the TCL input for the annotation.

You should aim for getting a line on the screen.  When you are able to
see what you are doing it will make the live easier.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

2017-06-09 5:06 GMT+02:00 Shubham Rathore :
> Hi,
>
> table.c for the annotation primitive has only a few functions left to be
> completed. Meanwhile, I was aiming to define the frontend pipeline i.e.
>
> the user input through "in" command
> porting the primitive details into the database
>
> I went through the tclscripts library, but found difficulty in some parts.
>
> It will be very grateful if I get some help regarding this part.( the files
> to be modified, their dependencies and which directories should I
> particularly look into)

I don't thing you must touch src/tclscripts for now.  Annotation is
only a primitive not a command.  Of course, if you want special
support for it you need to add the features to the GUI.  However, a
simple "in annotation" should work without touching tclscripts.

BTW, you mentioned brep functionality in your development log.  This
shouldn't be needed because the annotation is a non-geometric entity.

I'm keen to see your patch.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

2017-06-05 18:09 GMT+02:00 Shubham Rathore :
> Sir,
>  Regarding the surf_area, volume and the centroid functions. Surf_area and
> volume don't make sense here, but the centroid can be thought off, if the
> text if considered to be enclosed in a bounding box of a particular size.
> What do you think ?

Well, I think non of these functions really make sense:

surf_area: A 2D annotation has an area in the 3D space.  But it
depends on the scale which depends on the zoom on the screen, for
example.  With this, the area is highly volatile.

volume: OK, this indeed could make sense: It's always 0.

centroid: The annotation has a fix-point in the 3D model space but its
real position depends on the viewing angle.  I.e., we have a similar
situation as with surf_area here.

Therefore, it's reasonable to omit these functions.  They are intended
to inspect the model but the annotation isn't a real part of it.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

- You write first the length of the string to the stream ("network
> long") and then the string itself.
>
I thought of this before, but this ain't possible, as "ptr" cannot be
jumped directly to the string length variable without exactly knowing the
string length. Correct me if I'm wrong.


OK, here is my correction: If you read from the stream you get the string
length first from ptr and read "string length" bytes then.  When you write
to the stream you write the string length first and the string's bytes
afterwards.

I would have preferred this one.

However, you have to be prepared for side effects by introducing such a
construct in a version 4 database.


Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

>> > The struct bu_vls defines the char * before the string length. While
>> > writing
>> > the import function for the annotation primitive, one has to
>> > initialize(calloc) the char array to a corresponding size but the size
>> > is
>> > defined later. I checked out the case for other primitives for other
>> > structs
>> > as well. In every case the length is defined before the array, hence the
>> > exact space is alloted(malloc or calloc). How to deal with this ? Can
>> > the
>> > organisation of the vls_struct be changed?
>>
>> I don't get it.  The order of members in a struct is usually
>> unimportant.  Do you have a code example?
>>
>> However, what i can say is that you should deal with a bu_vls only via
>> the bu_vls_~() functions.  Never touch the member variables directly.
>> E.g. use bu_vls_cstr() to retrieve the string.
>> And, as an example of how to import and export strings you could look
>> at extrude's sketch_name.
>>
> I already had a look at other primitives import functions, the "char *" is
> allocated memory of length equal to NAMESIZE, i.e. 16 . but  the annotation
> label can have a length that the user desires. This is what I was trying to
> do :
>
> https://docs.google.com/document/d/1UaDU9o9G98_qGDLMe2wenU3MPL5WxBs00niFZT6Bk_I/edit?usp=sharing

I think I got it now.  The good news is that bu_vls isn't the problem ;)
In version 4 databases the element names were restricted to NAMESIZE
characters.  (This restriction isn't true for version 5 databases any
more.)  That's why the import routines copy always NAMESIZE characters
from the stream when they expect a string.

You have several options here:
- Ignore version 4 databases and support version 5 databases only.
E.g., the hrt primitive does it.
- Read/write a variable length string from/to a version 4 database
stream (the ptr variable).  There you have to determine the length of
the string.  I could imagine two solutions for this:
- The bytes of the string are copied to the stream and are
zero-terminated.  When reading from the stream you have to read from
it byte by byte until you reach the '\0' byte.
- You write first the length of the string to the stream ("network
long") and then the string itself.
  However, I don't know how the side effects with other functions as
g2asc are.  Therefore, ignoring version 4 databases is a valid
solution.

> Regarding the dev logs, I updated them on
> https://brlcad.org/wiki/Google_Summer_of_Code/2017 . I'll be updating the
> progress in the previous 2-3 days soon.

Thanks!


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

> I would like to know more about the functions that should be included in
> this file.
>
> From where exactly are these routines called from? Is it the rt^3 ?

These functions will be mostly called via the functions table
src/librt/primitives/table.c.  You have to add them there.

What do you mean with rt^3?  The repository branch?  It's for
testing/prototyping only.  You should stick to
svn.code.sf.net/p/brlcad/code/brlcad/trunk.

> I was working on the import functions and then I came across the functions
> ntohl(), bu_cv_ntohd() etc. I know these are related to the byte conversion
> (endianess), but I'd like to exactly know about their functioning.

These functions change the byte representation of numbers (~l for long
integers, ~d for doubles) from network format (big endian ieee) to the
machine (processor) specific host format.  The network format serves
as a well defined hardware independent binary format for numbers.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

There are probable some misunderstandings.
First, be careful with using the term "sketch".  A sketch is a BRL-CAD
primitive which isn't very interesting as it is because it's 2D and
has therefore no correspondence in the 3D world.  I.e. you won't find
much sketches in BRL-CAD models (except maybe in extrudes).  What you
mean is probable drawing/blueprint/model.

Second, the geometric objects which represent the real-world entities
and therefore are the basic components of the models are the regions
(special type of combinations: the Boolean combinations).  Imagine a
wall with a window in the middle.  It can be build from two cuboids.
But no canonical point from the underlying primitives (corners,
centroids, middles of the faces) would be a good anchor point for an
annotation with the stone type, for example.  I.e., at least at this
stage of development, I would leave the determination of the reference
point completely to the user.

Nevertheless, it's desirable to support it sometime with a GUI, e.g.
interactive with the mouse.


Regards,
Daniel

2017-05-14 20:26 GMT+02:00 Shubham Rathore <shubhamrathore1...@gmail.com>:
> Sir,
>
> Every sketch that is made will have a fixed set of points that can be
> annotated and these points correspond to  fixed points on each primitive
> that is a part of the sketch.
> - For ex. Consider an example of a radio - annotative points that are
> possible are the ones that correspond to each primitive i.e. rpp, rec, ell,
> tor, rcc. Annotative points corresponding to these primitives are basically
> the centroid points.
>
> Thus, from the point of view of the user, specifying the annotative
> primitive is easier when compared to the point coordinates, which may be a
> bit difficult to specify with precision. (or do you want user
> interactive[mouse input] selection of points?)
>
> This is what I thought, which may not be perfect. Your ideas and suggestion
> are welcome.
>
> Regards,
> Shubham Rathore(:gabbar1947)
>
> On Sun, May 14, 2017 at 12:54 AM, Daniel Roßberg <danielmrossb...@gmail.com>
> wrote:
>>
>> Shubham,
>>
>> What is the idea behind the "pipeline".  The reference point in the
>> model is a simple parameter (3 floating point numbers) e.g. for the in
>> command, or?
>>
>> Regards,
>> Daniel
>>
>> 2017-05-13 9:43 GMT+02:00 Shubham Rathore <shubhamrathore1...@gmail.com>:
>> > Hello,
>> > Thanks for the help. This is the plan that I aim to follow in the
>> > next
>> > few days. Reviews are appreciated.
>> >
>> >
>> > https://docs.google.com/document/d/1ITdGP4M7TgN-x0ih0Nb71RI-G0JlbJUQIZ6omh9VnDs/edit?usp=sharing
>> >
>> > Regards,
>> > Shubham Rathore(:gabbar1947)
>> >
>> > On Fri, May 12, 2017 at 3:06 AM, Christopher Sean Morrison
>> > <brl...@mac.com>
>> > wrote:
>> >>
>> >>
>> >> On May 11, 2017, at 02:17 PM, Shubham Rathore
>> >> <shubhamrathore1...@gmail.com> wrote:
>> >>
>> >>  Is it possible to retrieve all the primitives along with the
>> >> parameters
>> >> from a ".g " file.
>> >>
>> >>
>> >> I'm not sure what you mean.  If you have a .g file with all the
>> >> primitives
>> >> in it, then yes you absolutely could retrieve them all and their
>> >> parameters.
>> >> The "l" and "get" commands list parameters for primitives that exist,
>> >> for
>> >> example.
>> >>
>> >> However, I think you're asking whether there is a way to get a list of
>> >> all
>> >> primitives possible and their parameters.  Yes?
>> >>
>> >> For that, make sure you've seen the appendix in
>> >> http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf in case that's
>> >> what
>> >> you're after.  It's not all of them, but it's most.
>> >>
>> >> To get a dynamic list, that's a lot more tricky and the "practical"
>> >> answer
>> >> is that you cannot currently -- at least not a complete list.  That
>> >> would be
>> >> a simple addition someone could implement.  Otherwise, the "make"
>> >> command is
>> >> probably the closest which reports all primitives that can be
>> >> instantiated
>> >> automatically.
>> >>
>> >> Cheers!
>> >> Sean
>> >>
>> >>
>&g

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

What is the idea behind the "pipeline".  The reference point in the
model is a simple parameter (3 floating point numbers) e.g. for the in
command, or?

Regards,
Daniel

2017-05-13 9:43 GMT+02:00 Shubham Rathore :
> Hello,
> Thanks for the help. This is the plan that I aim to follow in the next
> few days. Reviews are appreciated.
>
> https://docs.google.com/document/d/1ITdGP4M7TgN-x0ih0Nb71RI-G0JlbJUQIZ6omh9VnDs/edit?usp=sharing
>
> Regards,
> Shubham Rathore(:gabbar1947)
>
> On Fri, May 12, 2017 at 3:06 AM, Christopher Sean Morrison 
> wrote:
>>
>>
>> On May 11, 2017, at 02:17 PM, Shubham Rathore
>>  wrote:
>>
>>  Is it possible to retrieve all the primitives along with the parameters
>> from a ".g " file.
>>
>>
>> I'm not sure what you mean.  If you have a .g file with all the primitives
>> in it, then yes you absolutely could retrieve them all and their parameters.
>> The "l" and "get" commands list parameters for primitives that exist, for
>> example.
>>
>> However, I think you're asking whether there is a way to get a list of all
>> primitives possible and their parameters.  Yes?
>>
>> For that, make sure you've seen the appendix in
>> http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf in case that's what
>> you're after.  It's not all of them, but it's most.
>>
>> To get a dynamic list, that's a lot more tricky and the "practical" answer
>> is that you cannot currently -- at least not a complete list.  That would be
>> a simple addition someone could implement.  Otherwise, the "make" command is
>> probably the closest which reports all primitives that can be instantiated
>> automatically.
>>
>> Cheers!
>> Sean
>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

2017-04-18 17:44 GMT+02:00 Shubham Rathore :
> Hi,
>
> regarding:
> - point2d_t *verts; // array of vertices that serve as control points
>
>
>  2d points! do we aim for the editor for annotations as well, as is the case
> for sketch. If not, then won't the points be 3D that will be later on
> projected into the 2D space while rendering it on the wireframe view ?
> Because if we don't aim for the editor then the user input through command
> line should comprise of the 3D points.

Of course 2D points because they are points on the 2D "paper" plane.
Editor or command line are only methods to create or change them in
the BRL-CAD database.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

OK, now my 2 ¢:

The container (this is what rt_curve is for the sketch) segments could be:
- line_seg (already defined)
- carc_seg (already defined)
- text (to be defined)
- beizer and nurb to be added later on

And:
- annotation_internal
- uint32_t magic;
- point_t V; // maps to the origin in the 2D system.
- size_t vert_count; // no. of vertices
- point2d_t *verts; // array of vertices that serve as control points
(- the container struct)

Looks like we are very close :)


Regards,
Daniel



2017-04-15 22:36 GMT+02:00 Shubham Rathore :
> Regarding the container for annotations:
> This is what I thought the container to look like-
>
> - line_seg (already defined)
> - carc_seg(already defined)
> - beizer and nurb to be added later on
>
> - annotation_internal
> - uint32_t magic;
> - point_t O; // maps to the origin in the 2D system.
> - size_t ver_count; // no. of vertices
> - point_t *ver; // array of vertices that serve as control points
> - struct bu_vls label; // text and symbols- UNICODE
>
> Is there something more that I need to add as of now ?
>
> Regards,
> Shubham Rathore(:gabbar1947)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

I have no ready made solution for you.  However, I would recommend to
look at the mged view setting commands (e.g. ae).  These will lead you
to the ged_view_update() function.  Maybe, analyzing this function
could give you some hints.

Reards,
Daniel

2017-04-15 20:29 GMT+02:00 Shubham Rathore :
> Hi,
>
> Regarding the transformation pipeline for the coordinates of the
> annotations:
>
> - What we see on our screens is nothing but the projection plane of the
> camera.
>
> - The 3D coordinates are mapped to the 2D plane using the camera or the
> projection matrix.(The camera must be calibrated accordingly)
>
> - We aim for view independent annotations. Thus there must be relation
> between the camera matrix and the annotation coordinate system.
>
> Can I get some details about camera positioning and the  camera projection
> matrices. That would be of great help.
>
> Regards,
> Shubham Rathore(:gabbar1947)
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Hooking ehy into analyze

[Daniel Roßberg]

Shubham,

As Sean has already mentioned, analyze_general() doesn't require the
volume function to be defined.  If the volume hook isn't defined in
the function table analyze will print a message saying that the volume
can't be determined.  Nevertheless the centroid and surface area will
be reported.

However, you have to make sure that analyze_general() will be called
in case of an ehy.  The analyze output you mentioned signals that
analyze_general() wasn't called.


Regards,
Daniel



2017-04-12 22:42 GMT+02:00 Shubham Rathore :
> Sir, I think volume needs to be defined before using  analyze on the ehy.
> The analyze_general() doesn't take care of this. All I get is "analyze:
> unable to process ID_EHY solid
> ". Thus defining the volume may resolve the issue.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

2017-04-06 19:38 GMT+02:00 Shubham Rathore :
> Hello,
>
> Annotations can't be ray traced.
> 1) Does the container for it, needs to be defined in the rt/geom.h ?

Yes.  Librt/geom.h contains de facto the BRL-CAD primitives, so keep
it as it is.

> 2) rt_annotation_internal comprises of some extrusion related parameters.
> Could you just explain ?

Redesign rt_annotation_internal to your needs.  The current structure
is only an idea/placeholder which has no implementation yet.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

2017-04-03 16:15 GMT+02:00 Shubham Rathore :
> Hi ,
>
> Oh fine! bounding box for the text . I get it ! . I can handle that.

:) Not so fast.  One part of the problem is to define the special
points of the annotation primitive's subelements (e.g. the corners of
the bounding box).  Another is to compute them (e.g. based on the
current font).  Then you need a methodology to reference them from
another subelement.  And last but not least one would probably need to
do computations with them (e.g. add 2 to the x coordinate).  These are
all nontrivial tasks.  That's why I would classify this as "think
about it if there is still time".

> I'd like to mention that the current timeline is tentative and there might
> be slight deviation, so I'll be updating the timeline in the coming days as
> I interact with the community and  get to know more and more about the time
> consumption of various parts of the project.

OK.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

>> Another feature extension would be relative coordinates, i.e. to
>> define a line with the length of the text.
>
> Sorry sir ! I didn't exactly get the last line. Can you please elaborate.

Assuming that you want to create a text with a rectangular frame of
straight lines around it.  How'll you do this?

Currently you need to know the size of the text on the screen and have
to calculate the lines accordingly.  But this changes if the text will
change, of even if the font is changed.  Wouldn't it be better to say
this relatively, e.g. a line goes from the text's min x coordinate - 2
mm to the text's max x coordinate + 2 mm?


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Raytrace Query: rt from command window

[Daniel Roßberg]

This created a heart for me:
in heart.s hrt 0 0 0 1 0 0 0 1 0 0 0 1 10

Regards,
Daniel

2017-04-02 4:31 GMT+02:00 Shailesh Tripathi
:
>> make hrt hrt
>> e hrt
>> rt -z1
>
> 'make hrt hrt' gives usage error as 'hrt' is not in the name list.
>
> Shailesh Tripathi
> B.Tech. Part-IV
> Electronics Engineering
> IIT-BHU (Varanasi)
>
> On Sun, Apr 2, 2017 at 7:08 AM, Vasco Alexandre da Silva Costa
>  wrote:
>>
>> On Sun, Apr 2, 2017 at 1:51 AM, Shailesh Tripathi
>>  wrote:
>>>
>>> Hello,
>>> The OpenCL rt finally works :)
>>
>>
>> Nice!
>>
>>>
>>> To test my code, could someone please give me some set of commands to
>>> successfully make and run raytrace over an HRT primitive.
>>> I tried:
>>>  http://brlcad.org/~Izak/Export_test.png
>>> But 'rt' command fails for this. (Error:
>>
>>
>> > make hrt hrt
>> > e hrt
>> > rt -z1
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)
>> Instituto Superior Técnico/University of Lisbon, Portugal
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GSoC Proposal

[Daniel Roßberg]

Alexander,

Your proposal is much to short.  It misses almost all relevant
information.  Please follow the guideline from our checklist
(http://brlcad.org/wiki/Summer_of_Code/Checklist).  Especially, have a
look at our requirement regarding the application's format
(http://brlcad.org/wiki/Summer_of_Code/Application_Guidelines).  You
can find links to some examples of awesome proposals here:
http://brlcad.org/wiki/Google_Summer_of_Code/2013


Regards,
Daniel

2017-04-02 17:11 GMT+02:00 Александр Павлишин :
> Hi all,
> Can somebody check my proposal,please?
> I shared it through GSoC page.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Shubham,

Keep the annotation primitive itself simple.  Some features as color,
thickness, font, etc. could be fully implemented afterwards.  I could
imagine an inheritance mechanism for them.  For now, we have the
application level only.  If there is time you could implement a
functionality which sets these values for the application.

Another feature extension would be relative coordinates, i.e. to
define a line with the length of the text.  However, your first
priority should be to implement a working simple annotation primitive.
Therefore:
- Must be features:
- Simple annotation primitive with lines, arcs, and texts
- Display them in the wireframe view
- ...?
- Desirable features:
- Overlay a rendered image with the annotations
- Setting the color, thickness, font, etc. parameters for the application
- ...?
- If there is still time:
- Extend the geometric shapes of the annotation, e.g. with filled
triangles and arcs
- Implement an inheritance mechanism for the parameters/attributes
- Think about how relative coordinates could be added
- ...


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

2017-03-26 22:56 GMT+02:00 Shubham Rathore <shubhamrathore1...@gmail.com>:
>
>
> On Sun, Mar 26, 2017 at 8:03 PM, Daniel Roßberg <danielmrossb...@gmail.com>
> wrote:
>>
>> Hi,
>>
>  Hello Sir, Now that was really helpful.
>
>> I.e.:
>> - Annotations can't be ray-traced.  (In fact, if they would be visible
>> for rays they would disturb the usual analysis done with BRL-CAD.)
>
>
>> - Annotations have their own coordinate system on the device (screen,
>> paper, ...).  If a letter is 5 mm high then these 5 mm are understood
>> as measured on the device.
>>
> So do you mean, adding no depth to the annotations or adding depth in a
> separate coordinate system exclusive to annotations? Because what I thought
> was of adding depth to the annotations, aiming for view independent
> geometry. Thanks for this.

No depth, the annotation coordinate system is 2D.

>> Nevertheless, annotations have a reference point in the 3D space which
>> will be identified with a point in the 2D annotation coordinate
>> system.
>>
> Oh yes! There should be a mapping between two coordinate systems.
>
>>
>> The annotation primitive has to address these issues.  Maybe the
>> sketch primitive could be used as a orientation when designing it.
>> The annotations display themselves in wireframe mode.  They need to be
>> able to switch the coordinate system to display (or "paper")
>> coordinates to draw themselves.  (In the future it could become
>> necessary to distinct between the viewing device and a blue-print
>> paper coordinate system.)
>>
>> Regarding the 4 questions:
>> 1): manual
>
> Do you expect to enter the location for the placement in the "in" command
> itself ? Correct me if I'm thinking differently.

Something like this.  At least the g2asc/asc2g programs require that
everything can be done on the TCL command line.

>> 2): 1
>
> Considering "annotation" as the head primitive. I feel the need to create
> some "sub-primitives", which comprise of options like "text", "leader line",
> "GD", "Tolerances" , "Hatches" etc. where each sub-primitive has its own
> desired parameters.

I mentioned the sketch primitive.  This is a kind of container with
lines, arcs, etc..  An annotation primitive could be implemented
similar.
Hatches are rather special views on solids than annotations.

Regarding 
http://www.engineersrule.com/wp-content/uploads/2016/10/image007-2.png:
I would ignore the not straight annotations for now.  They look very
artistic but the only effect you get is that they are only from one
direction optimal visible.  What's that supposed to mean?  Well, art
...
However, even this has to be done differently, in a way I already
mentioned: A paper coordinate system different from the screen
coordinate system.  In BRL-CAD, this could be set up in connection
with a combination.  I.e. a combination which contains solids and
annotations and defines a paper coordinate system for them.  Or, a
paper primitive which defines a paper coordinate system and contains a
combination of solids and annotations.
But, I don't see this as urgent as having the basic annotations.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Annotations: Implement support for 2D annotations, labels that can be added to geometry

[Daniel Roßberg]

Hi,

I'm not sure if this discussion goes into the right direction.  To
find out, I'll describe what's my understanding of annotations and its
consequences for a possible GSoC project:

The annotations are a very important step from a modeling system
toward a real CAD.  They are not necessary to represent a real world
3D geometry in a computer but to give a design to a workshop,
construction site, etc..  Without some text explaining it they
wouldn't be able to build what was designed.  This means, annotations
don't live in the 3D world but on the screen, paper, etc..

I.e.:
- Annotations can't be ray-traced.  (In fact, if they would be visible
for rays they would disturb the usual analysis done with BRL-CAD.)
- Annotations have their own coordinate system on the device (screen,
paper, ...).  If a letter is 5 mm high then these 5 mm are understood
as measured on the device.

Nevertheless, annotations have a reference point in the 3D space which
will be identified with a point in the 2D annotation coordinate
system.

The annotation primitive has to address these issues.  Maybe the
sketch primitive could be used as a orientation when designing it.
The annotations display themselves in wireframe mode.  They need to be
able to switch the coordinate system to display (or "paper")
coordinates to draw themselves.  (In the future it could become
necessary to distinct between the viewing device and a blue-print
paper coordinate system.)

Regarding the 4 questions:
1): manual
2): 1
3): -
4): no
Additional features are desirable but without a reliable foundation
all is nothing.


Just my 2 ct.
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] After compiling BRL CAD

[Daniel Roßberg]

Hi Saurabh,

> I have compiled BRL-CAD successfully. What is the next step that I should
> take?

Install it.  Then, run the programs, mainly mged and acher but have a
look at the others too.  Go through the tutorial:
http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf

Then, you should familiarize yourself with the source code.  You could
look at the bug list, reproduce some of them, and try to fix one.  If
you where successful submit a patch.

After gaining insight into BRL-CAD's internals you should be able to
make a proposal for a GSoC project.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GSoC Project Idea

[Daniel Roßberg]

Hi Ameya,

2017-03-17 6:35 GMT+01:00 Ameya Panse :
> Hi,
> I am writing this email to introduce myself as a prospective GSoC student
> with BRLCAD. I am currently in final year of my undergraduate studies at
> India's leading college IIT Madras.

Welcome!

> I must confess that I have not contributed in OpenSource but as they say it
> is never too late to start. I am determined to spend my summer working with
> an OpenSrc organisation and I believe that BRLCAD will provide me this
> opportunity.

GSoC students are usually new in open source development.  One
intention of GSoC is to involve more people there.

> I have downloaded the BRLCAD source code and have built it from source. I
> scanned through various projects of previous years.

Looks like you are on the right way :)  You should play around with
the different BRL-CAD programs too.  For example, you could do the
tutorial: http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf

> I would like to work on the following idea
>
> Heterogeneous paralleization's of LibICV using OpenMP.
>
> LibICV is BRLCAD's image processing library. The objective of this project
> would be to improve the performance of LibICV by taking parallelizing the
> code. I would also be looking at possible functionalities that coudl be
> added to this library.

Sounds interesting.  Keep us up-to-date about your plan.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] GSoc 2017: Advanced Sketch Primitive Editor

[Daniel Roßberg]

Hi Charu,

Nice to hear that you are interested in one of our projects.

Hello,
>
> I am Charu Tak and I want to contribute to the project " Advanced Sketch
> Primitive Editor 
> ".
> I have a background in C++, CAD and SOLIDWORKS.
>
> I have gone through the project description and I have few questions.
>
> 1.  Other than C++, basic knowledge of geometry what other pre-requisites are
> there to take up the project?
>

First, you should make yourself familiar with BRL-CAD.  Read through our
web site.  I would recommend to click every link and see what's behind it.
Download the sources from our Subversion repository, compile, and install
them.  A how-to is on our web site.

Play a little bit with the BRL-CAD programs, create geometries, etc..  You
can use the tutorials on our web site for guidance...


> 2.  Other than the the links on the project page, where should I refer to
> for getting a clearer idea for the project.
>

...Then you could have a closer look at the sketch primitive in BRL-CAD.
Crete some of them, make 3D objects from them (extrude).  Have a look at
the existing sketch editor.  Look at the implementation of the sketch
primitive to get an idea on how it works.

After exploring what's there and how it works and based on the descriptions
on the project page and some discussions with the developers on the mailing
list and IRC you should be able to write down a proposal for an own
project.  You can create an account for our wiki and put you project plan
at a sub-page of your user-page.  We linked the accepted proposals of the
last GSoCs in our wiki.  They are good references on how to write a GSoC
project proposal.


Regards,
Daniel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] MGED command removals

[Daniel Roßberg]

No objections.  I talked with a colleague, who uses mged frequently, about
it and he won't miss these commands.

Daniel

Am 16.02.2017 7:34 vorm. schrieb "Christopher Sean Morrison" :

>
> Continuing with a previously announced effort to eliminate features and
> tools from BRL-CAD that are infrequently used, we have identified the MGED
> commands listed below as candidates for removal.  As with the earlier
> listing of command line tools we want to provide plenty of advance notice
> and opportunity for user input, so please don't hesitate to provide
> feedback (pro or con) concerning their removal.
>
> Here's the list of some of the commands identified so far for outright
> elimination:
>
> ?devel  - list development commands
> ?lib- list library commands
> aproposdevel- search development commands
> aproposlib  - search library commands
> %   - escape to interactive shell
> animate - tool for building animation scripts
> db_glob - find objects matching glob, covered by commands like
> search and ls
> debugbu - set libbu debugging flags
> debugdir- print in-memory directory
> debuglib- set librt debugging flags
> debugmem- print librt memory map
> debugnmg- set libnmg debugging flags
> expand  - find objects matching pattern, covered by commands like
> search and ls
> loadtk  - manually initialize tk (developer command)
> match   - find objects matching name, covered by commands like
> search and ls
> memprint- print memory maps (developer command)
> preview - preview animation script
> regdebug- toggle display manager debugging
> regdef  - change defaults, covered by commands like attr
> rmats   - load views from 'savekey' file
> rrt - invoke remote rt
> savekey - save keyframe in file
> shaded_mode - get/set shaded mode, covered by draw -m#
> sync- forces filesystem sync
>
> Part of our plan is to reduce and consolidate many of the remaining
> commands into a smaller set of top-level commands with options.  (For
> example, bot_smooth and bot_decimate will become "smooth" and "decimate"
> subcommands to a new top-level "bot" command.)  The goal is to present to
> users a much smaller, more discoverable command set that increases the
> usability and convenience of working with BRL-CAD geometry.
>
> There are more details and an evolving roadmap evolving for anyone
> interested in helping accelerate progress.  Send me an e-mail if you want
> to get involved.
>
> Cheers!
> Sean
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Newbie to BRL-CAD

[Daniel Roßberg]

2016-11-13 22:26 GMT+01:00 Michal Hanus :
> Hi Daniel,
>
> Great hint! It works. I could not find the pscale command anywhere in the 
> manuals or tutorials.
> Are there any other similar functions for editing objects (correcting values 
> for A, B, C, H, V etc. of primitives) that would work in the Archer's CLI?

In principle yes, but...
Even pscale isn't implemented for every primitive yet.  See for the
files starting with scale_ in src/libged.  There are ptranslate and
protate commands (the p is for primitive) but they support only very
few primitives (see the corresponding translate_ and rotate_ files in
src/libged, rotate_arb_face is a command of its own).  For arb8s there
are moe_arb_edge and move_arb_face.  The whole thing is still in work.

For a general solution see at the end of
https://brlcad.org/wiki/Changing_the_properties_of_primitive_objects:
TCL Commands.

BTW, regarding your 3D printer: can you directly access it or only via
the manufacturers software?


Regards,
Daniel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] LGPL version 3 in BRL-CAD

[Daniel Roßberg]

Hi,

How do we handle LGPL version 2.1 incompatible licenses as the LGPL
version 3 used in FreeWRL?  It should be possible to include it with
dynamical linkage, the usual way in BRL-CAD.

I'm currently investigating patch 394
(https://sourceforge.net/p/brlcad/patches/394/) for obstacles to
accept it.


Regards,
Daniel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Newbie to BRL-CAD

[Daniel Roßberg]

OK, I see what you mean.  It looks like Archer has no commands for
interactive editing.  Even sed doesn't set it to editing mode.  It
runs the search command only.

However, in this particular case "pscale -r sphere.s abc 2" would do it.


Regards,
Daniel



2016-11-13 11:03 GMT+01:00 Michal Hanus <mikeha...@seznam.cz>:
> Hi Daniel,
>
> Thanks a lot for your help. I will try to compile BRL-CAD source both in 
> Visual Studio and from the VM image via SVN.
>
> Concerning Archer, is functionality of mged fully implemented in the Archer's 
> CLI? I tried to edit a simple sphere in both mged and Archer in their CLI but 
> it worked only in mged. I wrote this:
> in sphere.s sph 0 0 0 1
> e sphere.s
> sed sphere.s
> sca 2
> accept
>
> mged scaled the sphere twice, but the archer scaled only the view and the 
> accept command was rejected (Error: invalid command name "accept"). Am I 
> doing something wrong?
>
> Regards,
> Mike
>
> -Original Message-
> From: Daniel Roßberg [mailto:danielmrossb...@gmail.com]
> Sent: Saturday, November 12, 2016 6:52 PM
> To: BRL-CAD Developer Mailing List <brlcad-devel@lists.sourceforge.net>
> Subject: Re: [brlcad-devel] Newbie to BRL-CAD
>
> Welcome!
>
> 2016-11-11 21:32 GMT+01:00 Michal Hanus <mikeha...@seznam.cz>:
>> ...
>>
>> I downloaded binary Win version of BRL-CAD and I drew a few examples from 
>> Czech tutorials and I would like to ask some questions:
>>
>> 1.   What IDE would you recommend for easy compiling BRL-CAD from source 
>> code on Windows 7? I have worked with Visual Studio Professional 
>> 2010/2012/2015, Qt creator, Dev-C++, NetBeans, and eclipse (in this order of 
>> preference).
>
> I personally use MSVS professional 2013 but all three versions you mentioned 
> should work.  BRL-CAD uses CMake to set-up the build system.
> You can select your preferred MSVS version in CMake.
>
>> 2.   Is there any benefit in using Virtual Machine image of BRL-CAD as 
>> full IDE compared to “classic” Win 7 IDEs as above? If so, will I be able to 
>> update its version from 7.24 (which is on the BRL-CAD web) to the current 
>> 7.26.0.2?
>
> I don't think that the virtual machine image has an IDE for BRL-CAD 
> development.  The classical way to build is is to use make on the command 
> line.  I.e. if you want to use an IDE for development, rather than a simple 
> editor, I recommend MSVS.
>
> However, as Linux is de facto BRL-CAD's reference system, I recommend to have 
> a Linux system at hand as well.  You can maintain the sources with the 
> Subversion commands there (mainly "svn update").  For the first steps on 
> building BRL-CAD on Linux (e.g. in a virtual machine) see 
> http://brlcad.org/wiki/Building_from_SVN.
>
>> 3.   Is there any work currently being done in Qt in BRL-CAD?
>
> Yes, we started to port GUI components to Qt.  See libdm (display
> manager) and libfb (frame buffer) for it.  They require Qt 5 with setting its 
> config directory in CMake.  Some day the whole GUI could be build on Qt.
>
>> 4.   In Archer, I can translate a position of a primitive object 
>> entering to the “Object edit mode” window but I cannot change its dimensions 
>> by direct entering the values there. Is there any other method how to do it 
>> directly in Archer except by mouse-moving (unprecise) or by switching to 
>> MGED – Primitive Editor (which requires closing the Archer)?
>
> Hmm, you can use the mged commands in Archer as well, or?
>
>> 5.   I found a few bugs when using Archer, where can I report them?
>
> https://sourceforge.net/p/brlcad/bugs/
> Look if it isn't already reported yet ;)
>
>
> Regards,
> Daniel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Newbie to BRL-CAD

[Daniel Roßberg]

Welcome!

2016-11-11 21:32 GMT+01:00 Michal Hanus :
> ...
>
> I downloaded binary Win version of BRL-CAD and I drew a few examples from 
> Czech tutorials and I would like to ask some questions:
>
> 1.   What IDE would you recommend for easy compiling BRL-CAD from source 
> code on Windows 7? I have worked with Visual Studio Professional 
> 2010/2012/2015, Qt creator, Dev-C++, NetBeans, and eclipse (in this order of 
> preference).

I personally use MSVS professional 2013 but all three versions you
mentioned should work.  BRL-CAD uses CMake to set-up the build system.
You can select your preferred MSVS version in CMake.

> 2.   Is there any benefit in using Virtual Machine image of BRL-CAD as 
> full IDE compared to “classic” Win 7 IDEs as above? If so, will I be able to 
> update its version from 7.24 (which is on the BRL-CAD web) to the current 
> 7.26.0.2?

I don't think that the virtual machine image has an IDE for BRL-CAD
development.  The classical way to build is is to use make on the
command line.  I.e. if you want to use an IDE for development, rather
than a simple editor, I recommend MSVS.

However, as Linux is de facto BRL-CAD's reference system, I recommend
to have a Linux system at hand as well.  You can maintain the sources
with the Subversion commands there (mainly "svn update").  For the
first steps on building BRL-CAD on Linux (e.g. in a virtual machine)
see http://brlcad.org/wiki/Building_from_SVN.

> 3.   Is there any work currently being done in Qt in BRL-CAD?

Yes, we started to port GUI components to Qt.  See libdm (display
manager) and libfb (frame buffer) for it.  They require Qt 5 with
setting its config directory in CMake.  Some day the whole GUI could
be build on Qt.

> 4.   In Archer, I can translate a position of a primitive object entering 
> to the “Object edit mode” window but I cannot change its dimensions by direct 
> entering the values there. Is there any other method how to do it directly in 
> Archer except by mouse-moving (unprecise) or by switching to MGED – Primitive 
> Editor (which requires closing the Archer)?

Hmm, you can use the mged commands in Archer as well, or?

> 5.   I found a few bugs when using Archer, where can I report them?

https://sourceforge.net/p/brlcad/bugs/
Look if it isn't already reported yet ;)


Regards,
Daniel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Issue with new add_test()

[Daniel Roßberg]

Hi,

The new add_test CMake function breaks my BRL-CAD build.  During
configuration I get the following error:
CMake Error at CMakeLists.txt:558 (if):
  if given arguments:

"COMMAND" "STREQUAL" ""

  Unknown arguments specified
Call Stack (most recent call first):
  src/libbu/tests/CMakeLists.txt:16 (add_test)

Clearing the CMake cache, i.e. starting a new configuration, hasn't
helped.  I use Debian jessie with CMake version 3.0.2.

Changing line 558 in the main CMakeLists.txt to
  if ("${ARG}x" STREQUAL "x")
makes at least the CMake configuration happy.


Regards,
Daniel

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Orientation in a double connected edge list

[Daniel Roßberg]

Rakshika,

>> Would it be feasible to flip the orientation of a mesh part at the
moment we need it?
>
> How would we detect the disparity of the orientation for flipping it?

This is part of the question ;-)

>> Some thoughts regarding the implementation: I would recommend to
implement two functions in MeshConversion: AddTriangleToCache() and
ProcessCache() (the names can differ, the "Cache" (in fact a bag of
triangles) could be an own class as well). AddTriangleToCache() takes three
points and adds them to a bag of triangles, maybe with some preprocessing
as identifying nearby points. ProcessCache() performs the above described
algorithm. It uses the bag of triangles, a list of currently unmatched
edges, and maybe a list of more than two times used edges to do this.
>
> I'm a little unclear on how the 'Cache' class connects with the
'PolygonalMesh' class..

The cache class is very similar to the BRL-CAD BoT struct.  It serves as an
intermediate structure which will be filled from the original BoT and
emptied into the DCEL.  When the DCEL is set up and ready for use the
"cache" is empty and we don't need it any more.  It helps to track the
triangles while filling the DCEL.


Regards,
Daniel
--
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[brlcad-devel] Orientation in a double connected edge list

[Daniel Roßberg]

Rakshika,

There is one big issue left to make your mesh healing algorithm generally
applicable: The right orientation of the edges. Currently you test if the
normal of a triangle points towards the origin or away from it. This can
work for convex shapes but fails e.g. for a torus.

I want to outline an alternative approach here. Its details have to be
determined step-by-step.

First we see that your algorithm requires that every triangle has the same
orientation but it is not important if this is "clockwise" or
"counterclockwise". (Moreover, what's inside and outside depends on our
view on the space. It hasn't to be Euclidean.)

Therefore let's start with the first triangle from the bag, define this as
right oriented, and add its edges to the double connected edge list. Then
look for another triangle in the bag which shares with the first one an
edge and add it such that the common edge points to the other direction. Go
on with adding triangles until the bag is empty.

What kind of problems could arise here? There are at least 2:
- More than 2 triangles could have an edge in common (this is a nice
example of it:
https://upload.wikimedia.org/wikipedia/commons/b/b8/Modell_der_Weierstra%C3%9Fschen_p-Funktion_-Schilling._XIV._7ab._8_-_313._314-.jpg
).
- There are two or more not by an edge connected parts of the mesh.

We have to see how to deal with these issues best. For the start: If an
edge is used by more than two triangles don't use it for searching
connected faces; and, is it important that two unconnected parts of the
mesh have the same orientation? Would it be feasible to flip the
orientation of a mesh part at the moment we need it?

Some thoughts regarding the implementation: I would recommend to implement
two functions in MeshConversion: AddTriangleToCache() and ProcessCache()
(the names can differ, the "Cache" (in fact a bag of triangles) could be an
own class as well). AddTriangleToCache() takes three points and adds them
to a bag of triangles, maybe with some preprocessing as identifying nearby
points. ProcessCache() performs the above described algorithm. It uses the
bag of triangles, a list of currently unmatched edges, and maybe a list of
more than two times used edges to do this.

I hope I could make the basic idea clear. Details have to be determined in
further discussions.

Regards,
Daniel
--
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Zippering gaps testing

[Daniel Roßberg]

Rakshika,

This looks very promising.  Maybe you can play a little bit with the
tolerances to see the differences between zipping and stitching.  I'm
happy that you were able to solve the issues which made your live so
hard when you started.

Now, as the end of the coding period approaches, it's time to think
about all the small things which have to be done to polish up your
work:
- Is your coding style conform to what's written in HACKING?
- In shortestDistToLine() you allocate memory on the heap which would
better be on the stack, i.e. "double ortho[3];".  Are there more of
these?
- You shouldn't use malloc(), free() in MeshConversion_brlcad.cpp but
bu_malloc(), bu_free().  These functions operate on BRL-CAD structures
and should use the same methods as in the rest of BRL-CAD.  Here it
isn't a problem to use BRL-CAD functions because
MeshConversion_brlcad.cpp is only for BRL-CAD, it hasn't to be
portable.
- heal is an own command in mged and therefore should have an own file
in libged: src/libged/heal.c.
- Document your heal function e.g. for mged (in
doc/html/manuals/mged/mged_cmd_index.html?).


Regards,
Daniel



2016-07-21 21:39 GMT+02:00 Rakshika Bagavathy :
> Daniel,
>
> I'm attaching some more results from my tests. I'll attach the healed .g
> files for the two spheres too.
>
> Regards,
> Rakshika.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Finding closest edge approach

[Daniel Roßberg]

Right, you need a to implement analyze_heal_bot() in a C++ file in
libanalyze, and make it callable from C by declaring it as exten "C".  This
will be done automatically if you publish its prototype in analyze.h.

Regards,
Daniel
Am 21.06.2016 8:39 nachm. schrieb "Rakshika Bagavathy" <
rakshika.bagava...@gmail.com>:

> Daniel,
>
> I had looked at the other bot functions to see where they were declared...
> So, i'll create a header and C++ file to declare and define
> analyse_heal_bot() in libanalyze?
>
> Regards,
> Rakshika.
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Finding closest edge approach

[Daniel Roßberg]

Rakshika,

>> Additionally, the line intersects the edge only in a 2D projection but
>> probably not in 3D.
>
> This is true, so do i just check for intersection of the 2D projections
of the lines, i.e. setting the z coordinate to 0?

This is probable a bad idea.  Simply think of badly positioned triangles
(in 3D) near the vertex V.

However, write what you mean in code.  Then it's clear where and how you
call it (i.e. what it's good for) and how the algorithm should work.

> Also, i'm having trouble compiling the C++ headers in the mesh healing
files, when i include them in src/libwdb/bot.c for creating the
PolygonalMesh object. The cpp files get "no such file or directory" error
for the C++ libraries.

I could eventually say something about it if you had uploaded your complete
code ;-)

Regards,
Daniel
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Finding closest edge approach

[Daniel Roßberg]

Rakshika,

According to your description of the algorithm only edges with incident
faces containing the vertex will be considered (which sounded reasonable so
far).  Do you need to update your algorithm description there?

Additionally, the line intersects the edge only in a 2D projection but
probably not in 3D.

Regards,
Daniel
Am 21.06.2016 6:58 vorm. schrieb "Rakshika Bagavathy" <
rakshika.bagava...@gmail.com>:

Daniel,

Although the triangle 3 does not contain V, triangle 1 does. And we get to
triangle 1 through triangle 3. That is, for any edge we first check if it
contains the vertex V, or if the line from V to the edge intersects any of
the other two edges of the incident face. When the line from V to the edge
does not intersect the other two edges, it is an eligible edge.
Although, if the line just intersects any of the other two edges, it can be
deemed ineligible. That is, we don't even need to traverse the faces. If
the line intersects just one edge, then V is either inside the incident
triangle, or the line in non-crossing. We know that the former is not
possible, since it is a vertex. I will make those changes in the patch.

Regards,
Rakshika.

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Finding closest edge approach

[Daniel Roßberg]

E1 incident faces don't contain V.  So, why do you consider it?
Am 20.06.2016 20:05 schrieb "Rakshika Bagavathy" <
rakshika.bagava...@gmail.com>:

> Daniel,
>
> You had asked how one line would intersect another. So i made a simple
> drawing, which i've attached here.
> Here, we need to get the closest non-crossing edge for vertex V. And when
> we are considering edge E1, the perpendicular line from V to E intersects
> the edges of triangles 1, 2, and 3. So, we get triangle 3, from it we move
> to triangle 2. And finally at triangle 1, the vertex is a corner. Hence, we
> can mark this edge as ineligible.
>
> When we are considering E2, since an ortho projection is not possible, we
> get the feature pair to be a vertex- V1. The triangle 4 does not contain
> the vertex V, hence it is eligible to be the closest edge.
>
> Regards,
> Rakshika.
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports. http://sdm.link/zohomanageengine
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Project Intro: European Summer of Code in Space 2016

[Daniel Roßberg]

Yes, sure, irc is fine.  The problem is that I've no time for it in
the next week.  Checking my e-mail is all I can do.  The week after it
would be OK.

However, you could have a look at the C++ core interface meanwhile to
see if it fits your needs for the interface ("Create application
interface to brlcad libraries" of your project).  The source code is
in the rt^3 branch of the BRL-CAD subversion repository on
sourceforge.  It should compile well on the usual OSs.

Regards,
Daniel

2016-06-17 13:44 GMT+02:00 (Asad) Syed, Asadullah Hussain
<asadullah.huss...@tum.de>:
> That would be amazing. Kindly let me know when you have some time to do so 
> and the mode of discussion (irc etc)
>
> -Original Message-
> From: Daniel Roßberg [mailto:danielmrossb...@gmail.com]
> Sent: 17 June 2016 13:42
> To: BRL-CAD Developer Mailing List <brlcad-devel@lists.sourceforge.net>
> Subject: Re: [brlcad-devel] Project Intro: European Summer of Code in Space 
> 2016
>
> 2016-06-17 12:18 GMT+02:00 (Asad) Syed, Asadullah Hussain
> <asadullah.huss...@tum.de>:
>> Hi Daniel, this looks very interesting but I haven't been able to find its 
>> source anywhere. Is it proprietary?
>
> The *.exe is proprietary, that's true, but it may give you some ideas
> for your own work.   And we can talk about how it works, e.g. it is
> build upon Qt.
>
> The *.dll is part of the BRL-CAD project 
> (http://brlcad.org/wiki/BRL-CAD's_core_C%2B%2B_interface,
> brlcad/misc/win32-msvc/Dll), and I succeeded building similar libraries for 
> Linux an OS X.
>
> Regards,
> Daniel
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic 
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. http://sdm.link/zohomanageengine 
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://sdm.link/zohomanageengine
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Project Intro: European Summer of Code in Space 2016

[Daniel Roßberg]

2016-06-17 12:18 GMT+02:00 (Asad) Syed, Asadullah Hussain
:
> Hi Daniel, this looks very interesting but I haven't been able to find its 
> source anywhere. Is it proprietary?

The *.exe is proprietary, that's true, but it may give you some ideas
for your own work.   And we can talk about how it works, e.g. it is
build upon Qt.

The *.dll is part of the BRL-CAD project
(http://brlcad.org/wiki/BRL-CAD's_core_C%2B%2B_interface,
brlcad/misc/win32-msvc/Dll), and I succeeded building similar
libraries for Linux an OS X.

Regards,
Daniel

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Our of station for the weekend

[Daniel Roßberg]

Rakshika,

No problem, the weekends are free anyway.  You are expected to work
from Monday to Friday.

Is there already something you can show us regarding the zippering
gaps module?  And don't forget to update your development log.
However, I won't look into it before Monday ;)


Regards,
Daniel

2016-06-10 10:32 GMT+02:00 Rakshika Bagavathy :
> Daniel,
>
> I will be travelling this weekend. But I will make sure to spend enough time
> such that I finish my work.
>
> Regards,
> Rakshika.
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Project Intro: European Summer of Code in Space 2016

[Daniel Roßberg]

Welcome Asad,

This is an interesting and very useful project.  Have you seen this
one https://univemo.iabg.de/Download/BrlCadViewer30_setup.exe ?

Regards,
Daniel

2016-06-09 23:39 GMT+02:00 (Asad) Syed, Asadullah Hussain
:
> Hello Asad here,  I’m a student at Technical University Munich and will be
> working with brlcad under the umbrella of European Summer of Code in Space
> 2016. I will be working on a project titled: Geometry Viewer Application for
> BRL-CAD. The main idea is to build a geometry viewer application that
> generates a standalone double-clickable file that displays a given model
> file. This file should be viewable on any PC (initially just Windows). I
> have to interface librt and libdm with my standalone application in order to
> achieve this and would appreciate any pointers on my approach.
>
>
>
> I have primarily worked as a Systems engineer in the industry and recently
> held a position of DevOPs engineer at T-Systems. So if anything relevant
> comes up I am more than willing to contribute in tasks invloving automation,
> infrastructure, Continuous integration etc.
>
>
>
> Cheers,
>
>
>
> Technische Universität München
>
> Syed Asadullah Hussain
>
> MS Informatik
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Conversion files for mesh healing

[Daniel Roßberg]

2016-06-06 20:22 GMT+02:00 Rakshika Bagavathy :
...
> I'm attaching the link to the updated code:
> https://drive.google.com/open?id=0B7N8x571Yp6VLVVjYzNVZFAxajA

Hmm, does a healing algorithm really call initVertices()?

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Zippering gaps

[Daniel Roßberg]

Rakshika,

I'm not sure if I understood you right.
I would do it in two runs: 1st run zips everything below tolerance 1.
The 2nd run stitches everything below tolerance 2.  I.e. larger than
tolerance 2 means that it's a hole.

Does this fit to what you have in mind?


Regards,
Daniel


2016-06-07 10:34 GMT+02:00 Rakshika Bagavathy :
> Daniel,
>
> Is it okay to use just one method for filling gaps (zippering/stitching)
> based on the tolerance of just the starting edge of the free edge chain?
> That is to say, is it safe to assume that the error measures of constituent
> vertices of the free edge chain are uniform to an extent?
>
> If we have to decide on zippering/stitching based on the error measures of
> each vertex (and if those measures are not uniform) we'd have to shift
> between the two methods, which could complicate things.
>
> Regards,
> Rakshika.
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Re: [brlcad-devel] Conversion files for mesh healing

[Daniel Roßberg]

> I did think about changing the vector to a map. Then, i'd have to change the
> attributes of the structures DCEL_Vertex, etc. And the accessing code will
> become lengthier (and non-intuitive maybe?). Also, for edges the ID is not
> an integer, it's a pair of integers (the IDs of the two constituent
> vertices). Thus map for that would become ugly. So is it okay if i stick
> with vectors?

Sure.  You considered the alternatives well and decided to use the
vector.  That's OK.
BTW, you can use complex structures as keys for maps too.  They only
need to have a comparison operator.

> Whenever i need to add/remove/modify (remove functions will be trickier than
> the add and modify functions?) information in the meshes, i'd have to update
> both the DCEL and the native structure. So essentially, the access functions
> in the PolygonalMesh class will update both the DCEL and the rt_bot_internal
> structure? I will be adding these functions as i write the mesh healing
> algorithms.

You should have virtual protected methods in PolygonialMesh to update
the native structures.


Regards,
Daniel

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel