@Jeffrey Liu That’s the problem trying to fix windows build errors without windows... Can you provide an updated build log?
@Sean I'm updating to the most current version and trying again. It looks like the error was because of this but I believe that this has been fixed in the latest revision: C:\Users\JeffL\Downloads\Google Code-in 2019\Source\brlcad\src\libged\bot_dump.c(705,31): warning C4267: c1: fatal error C1083: Cannot open source file: 'C:\Users\JeffL\Downloads\Google Code-in 2019\Source\brlcad\src\libged\debug.c': No such file or directory
There is no debug.c anymore. It was renamed to debug.cpp. Maybe you need to rerun CMake to get the changed project file in Visual Studio, and to cleanup the libged project there.
@Daniel Rossberg it should shwoing this
BRL-CAD Release 7.30.3, Build 20191204
or 7.30.4 ?
I used cmake .. -DBRLCAD_BUNDLED_LIBS=ON -DCMAKE_BUILD_TYPE=Release (for a release build)
Daniel Rossberg it should shwoing this
BRL-CAD Release 7.30.3, Build 20191204
or 7.30.4 ?
Mine is 7.30.3, i.e. yours looks okay.
@Daniel Rossberg yep, sorry I should've clarified that I was building on a past revision at the time. The error seemed to have been due to the fact that another file was still referencing debug.c rather than debug.cpp, but I believe it has been fixed.
@Himanshu Sekhar Nayak Your rt^3 build looks odd. There is no doc
directory in its trunc.
@Daniel Rossberg yeah just checked now there is no doc directory
I went though this https://brlcad.org/wiki/SVN
@Jeffrey Liu My Visual Studio build was fine with revision 74420.
@Himanshu Sekhar Nayak I recommend a side-by-side checkout of brlcad/trunk (the usual) and rt^3/trunk.
is rt^3 at revision 74423.
?
I am recompiling and it should work now, the error occured with revision 74419 I think.
Himanshu Sekhar Nayak I recommend a side-by-side checkout of brlcad/trunk (the usual) and rt^3/trunk.
just done and still there is no doc
directory
is rt^3 at
revision 74423.
?
My last commit was the 74409.
hello Everyone
Hello!
r74424 finished compiling successfully for me. @Sean even though the errors are now fixed, could I still submit them for the bug report tasks?
I don't believe that they were mentioned prior to me reporting the build errors on Zulip.
r74424 finished compiling successfully for me. Sean even though the errors are now fixed, could I still submit them for the bug report tasks?
Sure, or you can safe it for a different bug later. A compilation bug due to a recent change isn't very "valuable" from a GCI task perspective, but a different bug in a tool or library would be, and even more so if it's one that you fix. The system may only let you claim one, don't recall.
Oh I see, I'll keep that in mind for the future.
It looks like the MS Windows build with Visual Studio is broken. I would guess that's because of a broken post build step, but I hadn't time for a deeper look yet.
BRLCAD_CONFIGEXE, where is the file located?
I'm trying to building MOOSE on windows, after configuring I see a lot of entries being "NOTFOUND", but the generation is done, when building I see this errors "cannot open include file"
Should I set the NOTFOUND directories/files manually?
Did you set BRLCAD_BASE_DIR and BRLCAD_VERSION variables in MOOSE's CMake configuration? CMake should complain, if they are missing.
It's similar to rt-cubed.
BTW, the moose_port of arbalest needs BRLCAD_MOOSE_DIR set with the directory of your MOOSE installation.
yes I set BRLCAD_BASEDIR to source root, and BRLCAD_VERSION to the version I found with mged -v
What is your BRL-CAD version?
7.34.3
The current Windows build is broken, at least for me. I'll see, if I can switch to a version which works.
BTW, did you install BRL-CAD, i.e. build the INSTALL target in Visual Studio? That's important.
I build the "All Targets", I did not install I guess, the binaries are in BRLCAD_BASEDIR/build/Debug
But there, they are not at the right place. FindBRLCAD.cmake depends on the directory structure of the installation.
Alright I'll install it then, but can we make FindBRLCAD.cmake to look at non-standard directory
Okay, in this case, you can try to set the NOTFOUND variables to the right values (not all are needed).
ok
@Nishanth not able to build arbalest yet ?
yes :sweat_smile: , I thought to get bit more familiar with cmake then figure out the issue
@Nishanth you set those variables in cmake gui by adding entry right?
What's wrong with installing BRL-CAD?
Brlcad build failing? I recently build from fresh commit 2 days ago and the build is fine. What went wrong ?
Visual Studio 2019? Or, maybe my last CMake config is a week old. I can retry with a clean build tomorrow.
BTW, most binaries were build. But, there are errors (19?), and the INSTALL installs only a few files. I.e., if you don't install the programs, you may see no issues.
Himanshu Sekhar Nayak said:
Nishanth you set those variables in cmake gui by adding entry right?
yes
I'll run Install target and try again
Nishanth said:
Himanshu Sekhar Nayak said:
Nishanth you set those variables in cmake gui by adding entry right?
yes
then by now rt-cubed and arbalest both should have been successfully build by now. What problems you are exactly facing? Variables path missing?
Nishanth said:
I'm trying to building MOOSE on windows, after configuring I see a lot of entries being "NOTFOUND", but the generation is done, when building I see this errors "cannot open include file"
Should I set the NOTFOUND directories/files manually?
This is the issue, I'm getting similar errors with rt-cubed. I'm going to try building again after installing brlcad
Hy! My name is Aqeel Ashraf. I am from pakistan. I applied in GSoc 2023. I am a C++ developer. I selected your organization because your organization works on c++ ,which maches my interest So I I want to contribute in your organization.I shall be very thankful to you if you make my chat with my mentor so it helped me in my project to make it effective so my chances of acceptance in GSoC 2023 becomes high. Again I shall be very thankful to you if you give me a chance to contribute.
Hy! My name is Aqeel Ashraf. I am from pakistan. I applied in GSoc 2023. I am a C++ developer. I selected your organization because your organization works on c++ ,which maches my interest So I I want to contribute in your organization.I shall be very thankful to you if you make my chat with my mentor so it helped me in my project to make it effective so my chances of acceptance in GSoC 2023 becomes high. Again I shall be very thankful to you if you give me a chance to contribute.
Nishanth said:
Nishanth said:
I'm trying to building MOOSE on windows, after configuring I see a lot of entries being "NOTFOUND", but the generation is done, when building I see this errors "cannot open include file"
Should I set the NOTFOUND directories/files manually?
This is the issue, I'm getting similar errors with rt-cubed. I'm going to try building again after installing brlcad
Can you show a screenshot of your vars setup and what missing path which are in red?
Aqeel Ashraf said:
Hy! My name is Aqeel Ashraf. I am from pakistan. I applied in GSoc 2023. I am a C++ developer. I selected your organization because your organization works on c++ ,which maches my interest So I I want to contribute in your organization.I shall be very thankful to you if you make my chat with my mentor so it helped me in my project to make it effective so my chances of acceptance in GSoC 2023 becomes high. Again I shall be very thankful to you if you give me a chance to contribute.
Hi @Aqeel Ashraf. Welcome to our community. Once you finalize a project that you want to work on then you can chat with mentors here. Here are some of the project ideas.
Btw you can shift to #general > general if you have any questions.
For a general start you can step into here.
Himanshu Sekhar Nayak said:
Nishanth said:
Nishanth said:
I'm trying to building MOOSE on windows, after configuring I see a lot of entries being "NOTFOUND", but the generation is done, when building I see this errors "cannot open include file"
Should I set the NOTFOUND directories/files manually?
This is the issue, I'm getting similar errors with rt-cubed. I'm going to try building again after installing brlcad
Can you show a screenshot of your vars setup and what missing path which are in red?
Nothing is in red, it gets configured and generated, but when building linking errors occur.
Now after Installing BRLCAD most of the errors are gone but still getting few linking errors for both moose and rt-cubed
Like this, Pipe.obj : error LNK2001: unresolved external symbol bu_setjmp_valid
And "ge" target is failing
Nishanth said:
Himanshu Sekhar Nayak said:
Nishanth said:
Nishanth said:
I'm trying to building MOOSE on windows, after configuring I see a lot of entries being "NOTFOUND", but the generation is done, when building I see this errors "cannot open include file"
Should I set the NOTFOUND directories/files manually?
This is the issue, I'm getting similar errors with rt-cubed. I'm going to try building again after installing brlcad
Can you show a screenshot of your vars setup and what missing path which are in red?
Nothing is in red, it gets configured and generated, but when building linking errors occur.
Now after Installing BRLCAD most of the errors are gone but still getting few linking errors for both moose and rt-cubed
Like this, Pipe.obj : error LNK2001: unresolved external symbol bu_setjmp_valid
And "ge" target is failing
Can you share a screenshot of what variables you set before building rt-cubed? Are you getting this message after build? ========== Build: 16 succeeded, 2 failed, 0 up-to-date, 0 skipped ==========
Forget about Pipe.obj, ge and bu*. Those are expected. No need to worry about it.
In your vs solution explorer, go to arbalest > source files > main.cpp
. Open main.cpp and click on play button above. This will able to open arbalest if you set variable Qt /bin correct. Otherwise it will shows not found some .dll
files that are needed for arbalest to run.
If you are able to run main.cpp then it will show arbalest. Screenshot-114.png
yes I'm getting 16 succeeded, 2 failed message
when running main.cpp I'm getting unable to start program access is denied, when trying to run arbalest.exe missing libbn.dll, libbv.dll, linnmg.dll, librt.dll errors popup. QT/bin is in PATH
Nishanth said:
when running main.cpp I'm getting unable to start program access is denied, when trying to run arbalest.exe missing libbn.dll, libbv.dll, linnmg.dll, librt.dll errors popup. QT/bin is in PATH
Looks like you have installed in C:
drive that's why it is not accessible.
Missing files popup because you have to set brlcad base dir path in your environment settings in windows.
You installed qt 5.14.2 ?
Also tried setting brlcad_basedir same results.
My qt version is 5.12.12
also tried running visual studio as administrator
Did you set for example C:\Users\Himanshu\Desktop\Workspace\brlcadBuild\Debug\bin
in your Path in environment settings?
Your qt bin path should be like C:\Users\Himanshu\Desktop\Workspace\brlcadBuild\Debug\bin
in Path
.
Btw I didn't installed brlcad, only build it and you can find mged
in YourBuild\Debug\bin
.
Btw in readme it is mentioned to install 5.14.2 https://github.com/BRL-CAD/arbalest#:~:text=Install%20and%20configure%20Qt.%20Qt5.14.2%20has%20been%20used%20for%20development%20of%20this%20project.
You can copy the BRL-CAD libbn.dll, libbv.dll, libnmg.dll, librt.dll, etc. in the directory where your arbalest.exe is, if their place is not in the PATH environment variable.
Daniel Rossberg said:
You can copy the BRL-CAD libbn.dll, libbv.dll, libnmg.dll, librt.dll, etc. in the directory where your arbalest.exe is, if their place is not in the PATH environment variable.
Ahh.. this can be a way too.
Arbalest starts, thanks for the help
Nishanth said:
also tried running visual studio as administrator
You should not do that, and it can cause issues down the road. Just a word of caution. If you did that in the past trying to overcome some problem, it could be necessary now, but it shouldn't be necessary to begin with. Just FYI.
I tracked down the causes for the build errors with Visual Studio. However, I'm still confused about that I seem to be the only one who sees this issues. I tested it with VS 2019 and 2022, and could reproduce the errors with both versions. But, it seems to make a difference, if I use the CMake distributed with VS or a separate installation. The version with VS could do the build.
1st issue: CMake in GDAL complains about SQLite3_~ and SQLITE3_~ beeing defined different. This can be fixed by changing lines 147 and 148 of gdal.cmake to camel-case.
2nd issue: OpenMesh, AssetImport, PROJ, and GDAL append a "d" at the debug binaries. But if they are accessed after their build, it's without this letter (they are in the Debug directory anyway).
I could probably fix this, but what bothers me is https://github.com/BRL-CAD/brlcad/commit/d216c04dc3195ae25657a46f4cd28a7808243fc8,
i.e. it looks like is has worked before, but for another reason no more?
Thanks @Daniel Rossberg ... Alas, I've not done a Windows build in a while as my focus has been on generating about 200k renderings, tracking down a Mac build error, and getting patch release 7.34.6 tested on other platforms. There was a tricky bug with nirt run within mged where it was hanging, and we just got that sorted out today (race I/O issue). That said, I am also tracking at least a couple issues with the state of the build on 'main' being unstable in some platforms. I hadn't seed the two issues you mentioned, but there are other errors I've encountered with gdal that will have to be resolved before 7.36 is ready to go (it's eta is by end of April).
Okay, good to know. In this case, I'll make up some fixes, which "work for me". If somebody gets an issue with them, please complain here...
Fun fact: In stand-alone CMake on Windows, CMAKE_BUILD_TYPE is empty. It generates configurations for all entries in CMAKE_CONFIGURATION_TYPES. I try to work around it with $<$<CONFIG:...
.
Daniel Rossberg said:
I tracked down the causes for the build errors with Visual Studio. However, I'm still confused about that I seem to be the only one who sees this issues. I tested it with VS 2019 and 2022, and could reproduce the errors with both versions. But, it seems to make a difference, if I use the CMake distributed with VS or a separate installation. The version with VS could do the build.
1st issue: CMake in GDAL complains about SQLite3_~ and SQLITE3_~ beeing defined different. This can be fixed by changing lines 147 and 148 of gdal.cmake to camel-case.
2nd issue: OpenMesh, AssetImport, PROJ, and GDAL append a "d" at the debug binaries. But if they are accessed after their build, it's without this letter (they are in the Debug directory anyway).
I could probably fix this, but what bothers me is https://github.com/BRL-CAD/brlcad/commit/d216c04dc3195ae25657a46f4cd28a7808243fc8,
i.e. it looks like is has worked before, but for another reason no more?
I have been having problems building BRL-CAD since last year. I failed to build it on ubuntu 22.04 in debug and release mode(succeed sometimes.. I can't reproduce it because I reinstalled the system). And I failed to build it on windows with VS 2019 in debug mode. The problems were still there at the beginning of this month. Actually, I'm working with ubuntu 20.04(build well in debug and release mode) and VS 2019 in release mode.
I had built brlcad again freshly like 10 days ago from this commit 880d2d
in VS 2022 with no build errors. Am I missing something? @Daniel Rossberg
Daniel Rossberg said:
Fun fact: In stand-alone CMake on Windows, CMAKE_BUILD_TYPE is empty. It generates configurations for all entries in CMAKE_CONFIGURATION_TYPES. I try to work around it with
$<$<CONFIG:...
.
Maybe need to delete the build directory? I've noticed an increase in instances where I've had to blow away the build dir because something in cmake updated and it didn't detect/regenerate correctly, or cached data from old variable settings was messing with new logic in unexpected ways.
Himanshu Sekhar Nayak said:
I had built brlcad again freshly like 10 days ago from this commit
880d2d
in VS 2022 with no build errors. Am I missing something? Daniel Rossberg
How did you the CMake configuration: With Visual Studio's build-in CMake? In this case, CMAKE_BUILD_TYPE is set and the build can work. If you use a standard CMake installation, CMAKE_BUILD_TYPE wan't be set (if you don't set it explicitly) and the Debug build should fail because of missing "d"s in the binaries' names of some 3rd party libraries. I.e., the Release build could work there too.
BTW, I do all main tests starting from a clean (empty) build directory. That's why it is very time consuming.
I did some changes on the configuration of 3rd party libraries for Windows: https://github.com/BRL-CAD/brlcad/tree/msvc-patch
You may want to give it a try and see, if it solves you problems. @Nishanth? I tested it successfully with MSVS 2022 and separate vanilla CMake for both Debug and Release build.
Unfortunately, the $<$<CONFIG:...
approach didn't worked, because it wan't be evaluated in all cases. (And it seems to be a very new feature with small differences between the last CMake versions.) That's why I hacked the configs of the libraries. I don't know, if this is okay.
I used to use standard but now almost exclusively use built-in, so that'd explain why I don't see it. Cliff and the CI system exclusively use standard cmake. For CI, CMAKE_BUILD_TYPE is set for one of them, but not all the configurations run on Windows from what I'm seeing..
Daniel Rossberg said:
Himanshu Sekhar Nayak said:
I had built brlcad again freshly like 10 days ago from this commit
880d2d
in VS 2022 with no build errors. Am I missing something? Daniel RossbergHow did you the CMake configuration: With Visual Studio's build-in CMake? In this case, CMAKE_BUILD_TYPE is set and the build can work. If you use a standard CMake installation, CMAKE_BUILD_TYPE wan't be set (if you don't set it explicitly) and the Debug build should fail because of missing "d"s in the binaries' names of some 3rd party libraries. I.e., the Release build could work there too.
BTW, I do all main tests starting from a clean (empty) build directory. That's why it is very time consuming.
Btw I always standard CMake installation to configure and generate.
hello after compiling brlcad on windows using msvs 2022 , i try to run mged , mged opens 2 windows usual behavior according to doc but one of it should have prompt here there is no prompt , archer on the other hand after displaying logo disappears and never return.
image.png
Is it related to access or privilege issue? error C1083: Cannot open include file: 'gdal.h': No such file or directory
I got this while building brlcad.
Himanshu Sekhar Nayak said:
Is it related to access or privilege issue?
error C1083: Cannot open include file: 'gdal.h': No such file or directory
No i didn't get any errors there were only warnings and none of them were similar to this
Diviyam Pathak said:
Himanshu Sekhar Nayak said:
Is it related to access or privilege issue?
error C1083: Cannot open include file: 'gdal.h': No such file or directory
No i didn't get any errors there were only warnings and none of them were similar to this
:sweat_smile: Mine is different from yours that I got now.
Himanshu Sekhar Nayak said:
I got this while building brlcad.
Was it same as mine ? If yes how did u fix it I think i am having bad cmake config i am still trying to find out
Diviyam Pathak said:
Himanshu Sekhar Nayak said:
I got this while building brlcad.
Was it same as mine ? If yes how did u fix it I think i am having bad cmake config i am still trying to find out
Nope. Can you build again from latest commit? It will work fine.
Even if gdal.h is there in src/other/ext/gdal/gcore/gdal.h
. Still build errors.
Those windows definitely don’t look like the build was complete or at least not successful. Did you do a build with everything enabled? Delete your build tree and retry with the cmake option -DBRLCAD_BUNDLED_LIBS=ON
While building brlcad, I saw
404>No download step for 'GDAL_BLD'
404>No update step for 'GDAL_BLD'
404>No patch step for 'GDAL_BLD'
404>Performing configure step for 'GDAL_BLD'
What are these?
Here what I am getting that I pulled from latest commit.
image.png
@Himanshu Sekhar Nayak are you doing a bext build or a default in-tree clone build? Check if you have a src/bext in your tree... That output looks like a bext build, which is our new way of managing external dependencies (like gdal) but it's not yet fully tested and isn't supposed to be enabled yet.
somewhere there's a bit of confusion in the build logic it would seem. might need to start fresh or at least delete your build dir, delete any src/bext, and make sure BRLCAD_EXT_DIR is not set.
Sean said:
Himanshu Sekhar Nayak are you doing a bext build or a default in-tree clone build? Check if you have a src/bext in your tree... That output looks like a bext build, which is our new way of managing external dependencies (like gdal) but it's not yet fully tested and isn't supposed to be enabled yet.
bext build? I cloned from main branch and tried to build but it is giving gdal cannot be found errors.
I tried 5 times still same.
do you have src/bext in the source tree?
was it a fresh build directory?
Sean said:
do you have src/bext in the source tree?
Nope, it's not there.
Sean said:
was it a fresh build directory?
Yes, I cloned today in the morning.
I was trying from previous night.
Right, I know you cloned fresh, but is where you're running cmake also new?
how'd you run cmake?
Sean said:
how'd you run cmake?
using GUI. Here is the variables.
image.png
did you let studio do it with the new automatic support in msvc2022 or do you run cmake manually?
Sean said:
did you let studio do it with the new automatic support in msvc2022 or do you run cmake manually?
Manually.
Yeah, I see that now :)
hm.
You got me stumped. That cmake output seems okay. Is there already a prior install in C:\program files\... 7.38.1 ?
I was bit in a hurry because I need to showcase arbalest but build is failing.
I just built today on Windows and on Mac, so it's a bit surprising, but I do now use the default build support in msvc, loving it.
Sean said:
You got me stumped. That cmake output seems okay. Is there already a prior install in C:\program files\... 7.38.1 ?
Nope, it's not there.
are you using 2022?
Yes
Sean said:
are you using 2022?
But without gdal, I built and ran arbalest. The thing is the mouse selection on objects is not working in arbalest that I had worked on.
how'd you build without gdal??
I thought we configured it so brlcad repo requires it
Sean said:
how'd you build without gdal??
After build failed, I went upon and built moose and installed it too because arbalest needs moose and brlcad.dll is only available inside installed moose dir.
arbalest runs fine but the mouse selection is totally not working.
I don't get how you build moose or arbalest thought since they depend on brl-cad being installed
So next question, basic sanity checks -- git status says origin/main and no edits or unknown dirs, yes?
where's your build dir in relation to the src dir?
Sean said:
So next question, basic sanity checks -- git status says origin/main and no edits or unknown dirs, yes?
Yep, no unknowns.
Sean said:
where's your build dir in relation to the src dir?
C:\Users\Himanshu\Desktop\Workspace\brlcad\src
and C:\Users\Himanshu\Desktop\Workspace\build
okay, so that's good
So yeah, I'd suggest trying msvc's integrated build. Can just ignore that Workspace\build exists for now -- msvc will create a new build dir in Workspace\brlcad\out if you simply open Workspace\brlcad in msvc.
After about a minute of opening the folder, you should see it starting to automatically run cmake in the console panel.
anywhere from a few seconds to a minute
depends how fast your machine is
default will be a Debug build -- which should be fine given the cmake settings you showed earlier
see if that has the same gdal.h error. cmake should take about 5 minutes, build takes maybe another 5-10 min
You'll notice there's no products or build types to worry about, just F5 or Build and it'll build everything.
okay I started with msvc, cmake started automatically.
I never knew msvc had this feature too. Have they added it recently?
It started in one of the 2022 betas that came out a couple years ago. they've been steadily improving it. I'm super impressed.
There's even a cmake debugger, you can actually set breakpoints in the build logic!
Okay, CMake generation finished.
everything auto-updates ... so as you edit files, it'll automatically re-run cmake or recompile sources and re-index sourcecode as you make changes.
git is also integrated on the right panel
can work with direct commit push/pulls or pull requests
Sean said:
can work with direct commit push/pulls or pull requests
This is a good feature.
Honestly, I've trash-talked msvc for years, and justifiably so, but 2022 has been a game-changer with all the new things they're integrating. With that cmake build, it's a simple point-and-click to set up additional configuration targets in addition to x64-Debug
and not just obvious stuff like x64-Release, but you can build WSL binaries or even cross-compile and build Linux binaries
(which also run on Windows and work within the msvc debugger)
Sean said:
and not just obvious stuff like x64-Release, but you can build WSL binaries or even cross-compile and build Linux binaries
What !!! I can't believe this is working also.
Btw where should I go next to build? I can't figure out. Is it in C:/Users/Himanshu/Desktop/Workspace/brlcad/out/build/x64-Debug
?
What do you mean "go next to build"? You mean after cmake finishes?
Build menu up top, there's an option to build everying
everything will build in the out/build/x64-Debug build dir (that's where it ran cmake), so there will be an out/build/x64-Debug/bin/rt.exe for example
I haven't actually tried installing from cmake in a really really long time, but that'd be the next thing to check, where it was configured to install to, and to actually install -- or configure moose to use the build dir as an install dir -- that should work too I'd think
Oops, I thought to I have to go to build folder and again start msvc to start the build.
Nope, it's all integrated right there. They just don't show you the million targets and products and such. It's a simplified view.
Hmm, I started building now. 850/5304
:grimacing:
I've found the automatic rebuilding to be amazingly effective. If you want to not rebuild the world every time, there is a Build->this file option, which will build every dependency leading up to that file (all libs it depends on) and then that file.
Still same CMake Error at C:/Users/Himanshu/Desktop/Workspace/brlcad/out/build/x64-Debug/src/other/ext/GDAL_BLD-prefix/src/GDAL_BLD-stamp/GDAL_BLD-build-Debug.cmake:47 (message):
Stopping after outputting logs.
Also I got
Error C1189 #error: The C++ Standard Library forbids macroizing the keyword "bool". Enable warning C4005 to find the forbidden define. C:\Users\Himanshu\Desktop\Workspace\brlcad\out\build\x64-Debug\brlcad C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\xkeycheck.h 54
damn
what's weird is there hasn't really been any changes to src/other/ext since last year in the fall
all references I'm seeing online curiously indicate that C1189 error is from msvc2019 and was later fixed.. I'm not seeing any #define bool in the source or build dirs for gdal
can you double-check your windows PATH environment setting? make sure there's not another msvc in the path somewhere in there...
echo %PATH% in a command shell should be enough
GUI method described here: https://phoenixnap.com/kb/windows-set-environment-variable
Sean said:
how'd you build without gdal??
FWIW, you can disable the GDAL components with BRLCAD_ENABLE_GDAL=OFF
I started again. Now the build is not complaining for gdal. :face_with_raised_eyebrow:
Sean said:
Those windows definitely don’t look like the build was complete or at least not successful. Did you do a build with everything enabled? Delete your build tree and retry with the cmake option -DBRLCAD_BUNDLED_LIBS=ON
hello, I built again with same cmake flags this time all binaries are working correctly, I think problem was, I didn't build the ALL_BUILD solution in msvs
I've opened a BRLCAD file in Archer 7.38.0 and would like to export as an STL file but I receive the Error "wrong # args:should be "set varName ?newValue?"
@B Stew Sounds like a great opportunity to create a patch if you can figure out what's wrong, fix it, and submit that as a patch ;) That said, you can convert to STL via the command-line as well using "gcv" or "g-stl" -- that's the typical method. Archer is considered beta, so you will find issues.
@Sean ,I have successfully build brl-cad with appleseed, but when I run art with args "Debug/bin/art.exe Debug/share/db/moss.g all.g":
OSL headers not found.
osl: No .oso file could be found for shader "as_plastic"
osl: Could not find shader "as_plastic"
error adding shader "as_plastic" for layer "shader_in".
what should I do to fix this error?
platform : windows,vs2022,appleseed 2.1
I infer that the serch paths for oiio and osl were error:
setting oiio search paths to D:\User\Jinke\brl-cad\build_appleseed\build-2\src\art\output/shaders:D:/User/Jinke/brl-cad/build_appleseed/build-2\shaders/max:D:/User/Jinke/brl-cad/build_appleseed/build-2\shaders/appleseed
setting osl shader search paths to D:\User\Jinke\brl-cad\build_appleseed\build-2\src\art\output/shaders:D:/User/Jinke/brl-cad/build_appleseed/build-2\shaders/max:D:/User/Jinke/brl-cad/build_appleseed/build-2\shaders/appleseed
I tried to change path by :
asf::SearchPaths resource_search_paths;
resource_search_paths.set_root_path("D:/App/appleseed");
resource_search_paths.push_back_explicit_path("D:/App/appleseed/shaders/appleseed");
resource_search_paths.push_back_explicit_path("D:/App/appleseed/shaders/src/appleseed");
bool tmp = resource_search_paths.exist("as_plastic.oso"); //true
but it doesn't work.
I have solved this problem, and I found there are something wrong when compling brl-cad with appleseed on windows, such as:
//art.cpp
ArtTileCallback artcallback;
//tile.h
class ArtTileCallback
:public renderer::ITileCallback{
void on_tile_begin(
const renderer::Frame*, //frame
const size_t, //tile_x
const size_t, //tile_y
const size_t, //thread_index
const size_t //thread_count
) {;}
}
but renderer::ITileCallback declares that:
virtual void on_tile_begin(
const Frame* frame,
const size_t tile_x,
const size_t tile_y) = 0;
whick makes artcallback fails to instantiated.
There are many similar errors as well, Can I assist in fixing these issues?
I have successfully build brl-cad with appleseed and generated picture like this:
art.png
@fall Rainy This is on Windows? Which version of appleseed are you building against?
Yes, it is on Windows, compiled by visual studio 2022, appleseed 2.1-beta(lastest version)
@starseeker I have submitted a pull request(#117), please review it
That's awesome progress @fall Rainy and I saw your github pull request too. I started reviewing it. I assume you used pre-built appleseed, yes?
Or did you also compile 2.1-beta from source?
@Sean I use both pre-built appleseed and coplie 2.1-beta from souce. I found this issue was caused by on_tile_begin() and on_progressive_frame_update(),appleseed 2.0 updated these two methods.
And I have already demonstrated the differences between these two versionspull #117
I have attached my proposal to this pull request. I hope to familiarize myself with BRL-CAD and Appleseed by fixing this bug, in preparation for future projects. If you can help review my proposal, I'd really appreciate it!
fall Rainy said:
I have attached my proposal to this pull request. ...
Hi @fall Rainy, we won't accept your proposal text in our repository :wink:. A better, often used way is to draft it in a Google Docs document and share its link. Then, you can create the final GSoC proposal from it.
Thanks! I have create a link to my research proposal:GSoc proposal:Rendering with Neural Intersection Functions
fall Rainy said:
Thanks! I have create a link to my research proposal:GSoc proposal:Rendering with Neural Intersection Functions
This looks pretty good. You certainly have done well demonstrating competency with appleseed -- curious why you're not proposing to work on https://github.com/opencax/GSoC/issues/71 ? Note that you don't need to involve appleseed to work on the neural intersection project -- the original vision there was an acceleration for rt_shootray() in LIBRT, not via BrlcadObject in the 'art' renderer. The 'art' renderer does physically based rendering (i.e. MUCH more than intersection testing).
I uploaded some materials that should be of assistance from the prior effort to https://brlcad.org/design/neural <-- see if that helps understand the prior effort and what you might do next. Also note, your experience with appleseed is just as interesting if not even more interesting, if https://github.com/opencax/GSoC/issues/71 is of interest, given your demonstration.
Thanks for your advice. I have updated my research proposal:Rendering with Neural Intersection Functions
Hi @fall Rainy and thx! On quick inspection it looks like the write up is reasonable but there alas won’t likely be time to go through it in detail until after the deadline. But it looks good, like I said. If you have not already, please do submit a code change (a pull request for something meaningful) soon as possible even if it’s after the deadline. If you have already, do be sure to cite it in your proposal. That’s arguably the most important aspect in evaluating any candidate’s proposal.
hello, i need das program to star, but instead i ended up here can anyone help me about the program ho to get it for freee?
@Konstantinos sorry I don't understand your question. Can you try restating it again a different way? If you're referring to BRL-CAD -- it is available for free.
@Konstantinos, does this link https://github.com/BRL-CAD/brlcad/releases help? You can download e.g. BRL-CAD_7.38.2_win64.msi and install the software from it.
Last updated: Jan 09 2025 at 00:46 UTC