@starseeker I can fix the decompress fast deprecation in Jan. I don't believe safe is the one we want, but I can check it.
OK, I won't worry about it then
https://fossies.org/linux/lz4/doc/lz4_manual.html down at the bottom is where they recommend LZ4_decompress_safe
or more officially https://github.com/lz4/lz4/blob/dev/doc/lz4_manual.html
thanks
from that, looks like they're recommending it more from a security position than performance, and that they made decompress_fast a lot slower by adding some checks
which is to say that our usage would slow down if/when we update, so in that scenario, using safe will be faster than the now-slow 'fast', but still may not be good for us. I tested safe during development and recall it being not as good, so may have to revisit our options.
/me winces
not a problem, we just might see a tiny performance dip
Our bundled libs could get rather tricky with appleseed... they have a lot of their own copies of things, and it could get interesting linking both librt and appleseed in if we're on different versions. libz, liblz4 and libpng I definitely see right off, and there are a few others that may be issues down the road.
Crud. Yep, the art build doesn't like bundled libs - complains about png
Oh well, should be good enough for the purpose
Our bundled libs could get rather tricky with appleseed... they have a lot of their own copies of things, and it could get interesting linking both librt and appleseed in if we're on different versions. libz, liblz4 and libpng I definitely see right off, and there are a few others that may be issues down the road.
Shoot, that seems like a big issue I'm going to encounter in the future... any idea how I would be able to resolve this?
The most straightforward is probably to try and have BRL-CAD's build use appleseed's libs (or rather compatible versions of them) as system libs instead of building our own. That's not something I usually do with Windows, so I'm not sure how it will go, but that's the most straightforward of the options.
The other options involve rebuilding appleseed using compatible libs or our own src/other libs, which based on my first round with it is going to be quite a job.
Hmm... yeah I asked Franz about it as well and he said something similar (but to have appleseed use BRLCAD's libs)
If you can get appleseed building on your system that might be an option.
It might work better with MSVC, actually - Ubuntu Linux is using a newer version of GCC by default than the one Appleseed currently specifies, so I get build errors when I try it out of the box. Ultimately correctable of course, but not something I have time for at the moment - C++ build errors are sometimes... interesting to figure out.
Alright, I'll try to work it out once I get to it. Thank you for your insight!
@Jeffrey Liu If it gets too frustrating one option might be to use VirtualBox to set up a Ubuntu VM, and then grab the binary and build BRL-CAD using system libs the way I specified in the art.cpp file - you'll have to install some devel packages on Ubuntu per the doc/Readme.Linux file (as well as the libpng and libz devel files based on my own experience) but I did get as far as a running program that way.
I do have Debian ready to dual boot if that's ok, do you mean the appleseed binaries?
On Windows I can only recommend to use the brlcad.dll. It has everything compiled in, even the C library. The only dependency is the nt.dll.
If you don't like the C++, you can build your own version from misc/win32-msvc/Dll.
@Daniel Rossberg Sorry if I'm understanding incorrectly, but if I am trying to add a program within BRLCAD itself while linking to another application, then I can't use the brlcad.dll, right?
The brlcad.dll is self-containing. It contains BRL-CAD's core libraries and is intended for use in other programs, maybe like appleseed. If you have already an appleseed plugin set-up, you need to add one additional library only.
Sorry, I still don't think I understand - if I were to try to call appleseed functions from BRLCAD (for an art command in MGED), would brlcad.dll be the ideal solution?
What do you mean by "from BRL-CAD"?
I can't find a brlcad in the bin directory ;)
i think the next set of appleseed integration tasks is to create some sort of command in MGED, "art", which renders the BRLCAD geometry database using appleseed rendering.
Therefore, you mean mged and archer, and libged. Which applesed function do you want to call?
Did you already tried to add the appleseed library as a dependency to libged?
I haven't really gotten that far yet, but I think I would be able to look at some of the appleseed src to figure it out. The general idea after "art" is called, I think, would be to generate an appleseed project and then calling appleseed rendering using that project.
Did you already tried to add the appleseed library as a dependency to libged?
Not yet, I'm still working through some other tasks before resuming appleseed #7
On the other hand, it could be better to write an appleseed program which will be called from libged, similar to the rt command, which calls the rt
program.
Yep, that's what I was thinking (or what is entailed in the task description, I suppose). In that case, I would need to link appleseed libraries, right?
This appleseed_rt would live in the appleseed program space, and could use a brlcad.dll for reading and ray-tracing .g files.
Ohh, and then I could just call this appleseed_rt whenever "art" is called from MGED?
Right, just like rt
.
art as appleseed-rt
Alright, thanks so much for your help! I'll look into it when I get back into the task set - I haven't really looked at the inner workings of rt
yet
Keep it simple, for the beginning.
The src/rt/art.cpp program is already set up (given the presence of a binary appleseed) to link both librt and appleseed's library into a single executable. It's a command line program, not an MGED/Archer command
libged doesn't enter into the picture (yet) - but the problem remains when trying to link both appleseed (which depends on png/libz) and librt (which also depends on libpng/libz) into the same executable when they are using different versions of those libraries.
It may be static linking would help with that - I've not experimented with that route.
Oh wait, so at the moment, you can already run art.cpp through the command line if you have appleseed installed?
@Jeffrey Liu You can run the program, but all it will do is run the helloworld example from appleseed. The idea (if you can get it to behave, which currently requires the steps I was talking about earlier with getting BRL-CAD and Appleseed using compatible libraries) would be to take the work done so far to use librt as a backend for the Appleseed rendering and incorporate it into the art.cpp code.
I deliberately staged the art.cpp binary in src/art so students could use that as a starting point rather than having to wade through getting librt and appleseed into the same executable - hopefully it should now be fairly straightforward to get the art executable to generate a png image which is the rendering you were showing earlier in your screenshots.
src/rt/art.cpp rather, not src/art
If we can get that far (and ideally look at things like mapping material settings as well) it will be worth it to wade into making Appleseed build with BRL-CAD compatible dependencies so we can make everything work seemlessly, but that's a slog - we need to be sure Appleseed rendering will work before tackling it.
Ah ok, so when you say use librt as the backend, you mean use rt_shootray() and such to provide the necessary information, right?
Yes.
#GoogleCodein Hi I am Omega Cuber and I am participating in GCI and I like the tasks related BRL-CAD as it helps in 3D design.
Last updated: Jan 09 2025 at 00:46 UTC