| 00:49.33 | *** join/#brlcad LordOfBikes (~armin@dslb-178-010-188-152.178.010.pools.vodafone-ip.de) |
| 01:25.17 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 02:13.32 | starseeker | OK, so it looks like mged and rtwizard work with 8.6, but archer isn't happy |
| 02:13.37 | starseeker | isn't sure why yet |
| 02:21.13 | Notify | 03BRL-CAD:starseeker * 68427 brlcad/branches/tcltk86/src/tclscripts/archer/Archer.tcl: update Tktable version |
| 02:46.36 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:24.05 | Notify | 03BRL-CAD:starseeker * 68428 brlcad/branches/tcltk86/src/archer/archer_launch.tcl: fix Tktable version |
| 03:26.19 | Notify | 03BRL-CAD:starseeker * 68429 (brlcad/branches/tcltk86/src/archer/archer_launch.tcl brlcad/branches/tcltk86/src/archer/plugins/Wizards/humanwizard/HumanWizard.tcl and 7 others): trying to treat Archer and ArcherCore as defining global variables seems to be iffy with the latest itcl/itk. Temporarily switching these out gets us further, but after that I'm getting a low level Tcl crash message from the init.tcl script. |
| 03:27.08 | Notify | 03BRL-CAD:brlcad * 68430 brlcad/trunk/NEWS: generalize carl's work to more than just help options -- he worked on overall command option consistency as well as making many manual pages more consistent. |
| 03:27.38 | Notify | 03BRL-CAD:brlcad * 68431 brlcad/trunk/TODO: 63406 needs docs if 7.24.6 matrix editing doesn't work. |
| 03:31.32 | Notify | 03BRL-CAD:brlcad * 68432 brlcad/trunk/doc/docbook/system/man1/rt.xml: in the process of making rt's manual page match rtedge, he incorrectly migrated a comment about -o disabling parallel processing. that's only true with rtedge because of how it seeks around the buffer and needs this in order |
| 03:36.02 | Notify | 03BRL-CAD:brlcad * 68433 brlcad/trunk/src/rt/opt.c: ws cleanup and change >= 180 back to > 179 |
| 03:37.18 | starseeker | isolates a behavior difference between itcl 3.4 and itcl 4 |
| 03:37.28 | starseeker | we'll see if it's considered a bug or not |
| 03:37.41 | starseeker | there's a deeper problem, but at least that's a start... |
| 03:39.57 | Notify | 03BRL-CAD:brlcad * 68434 brlcad/trunk/src/proc-db/tube.c: clearly denote floating point |
| 03:49.28 | Notify | 03BRL-CAD:brlcad * 68435 brlcad/trunk/doc/docbook/system/man1/brlcad.xml: high resolution flags no longer exist. -h is still reserved, albeit for help now |
| 03:56.34 | Notify | 03BRL-CAD:brlcad * 68436 brlcad/trunk/doc/docbook/system/man1/fblabel.xml: lowercase high res flag no longer exists, so adapt to uppwercase one remaining |
| 04:02.09 | Notify | 03BRL-CAD:starseeker * 68437 (brlcad/branches/tcltk86/src/other/itcl/CMakeLists.txt brlcad/branches/tcltk86/src/other/itk/CMakeLists.txt): relative dir positions changed |
| 04:07.15 | *** join/#brlcad tandoorichick (~rakshika@117.231.198.139) |
| 04:20.12 | Notify | 03BRL-CAD:brlcad * 68438 brlcad/trunk/TODO: added copyrighted images, but must preserve attribution and copyright notice from ayam dev |
| 04:21.50 | Notify | 03BRL-CAD:brlcad * 68439 brlcad/trunk/AUTHORS: lastname, firstname - credit gustave with his windows SMP support contributions |
| 04:23.55 | Notify | 03BRL-CAD:brlcad * 68440 brlcad/trunk/NEWS: Cliff not just removed support for old rle format, he removed the deprecated tools. thus, user visible and needing a final callout |
| 04:26.55 | Notify | 03BRL-CAD:starseeker * 68441 brlcad/trunk/src/tclscripts/archer/images/CMakeLists.txt: Add Ayam license file. Think it's just the brep icons so far, but should check to see if there are others that improve on what we're currently using. Should probably come up with some way to use icv to autogenerate the boolean variations at build time... |
| 04:27.29 | Notify | 03BRL-CAD:starseeker * 68442 brlcad/trunk/TODO: Added license file |
| 04:30.44 | Notify | 03BRL-CAD:brlcad * 68443 brlcad/trunk/TODO: looks like 61494 is user vis |
| 04:31.53 | Notify | 03BRL-CAD:brlcad * 68444 brlcad/trunk/TODO: bob's addition of fbclear to archer is user vis worth mention |
| 04:38.48 | Notify | 03BRL-CAD:starseeker * 68445 (brlcad/branches/tcltk86/src/other/itcl/CMakeLists.txt brlcad/branches/tcltk86/src/other/itk/CMakeLists.txt): simplify version number handling |
| 06:41.59 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 08:02.34 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 08:08.06 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 08:50.00 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) |
| 09:05.39 | *** join/#brlcad teepee] (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 09:22.53 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 09:50.32 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) |
| 09:50.39 | *** join/#brlcad davee_ (~davee@71-83-188-23.dhcp.lnbh.ca.charter.com) |
| 09:58.23 | *** join/#brlcad tandoorichick (~rakshika@117.249.203.55) |
| 10:20.02 | *** join/#brlcad tandoorichick (~rakshika@103.207.140.226) |
| 11:35.53 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 11:57.31 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 12:12.07 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 13:22.15 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:55.00 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 15:16.02 | Notify | 03BRL-CAD:starseeker * 68446 (brlcad/branches/tcltk86/src/other/itcl.dist brlcad/branches/tcltk86/src/other/itk.dist brlcad/branches/tcltk86/src/other/iwidgets.dist): Remove a few files we aren't using |
| 15:26.17 | *** join/#brlcad Mathnerd314 (~quassel@supertux/Mathnerd314) |
| 15:29.12 | Notify | 03BRL-CAD Wiki:Heliogalvan * 0 /wiki/User:Heliogalvan: |
| 16:12.17 | Notify | 03BRL-CAD:starseeker * 68447 (brlcad/branches/tcltk86/src/other/itcl/CMakeLists.txt brlcad/branches/tcltk86/src/other/itcl/generic/itcl.decls and 17 others): Back down from itcl/itk 4 to latest 3.4 - rtwizard still seems to work, and archer still fails with "cannot access object-specific info without an object context" |
| 16:17.42 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:26.10 | Notify | 03BRL-CAD:starseeker * 68448 brlcad/trunk/src/rt/opt.c: Looks like stray comma got added |
| 16:28.45 | Notify | 03BRL-CAD:starseeker * 68449 (brlcad/trunk/src/other/incrTcl/itcl/doc/Class.3 brlcad/trunk/src/other/incrTcl/itcl/doc/List.3 and 87 others): Upgrade to latest Itcl/Itk 3.4. Mostly this is a test - this version of Itcl/Itk runs archer with 8.5, but not with 8.6 |
| 16:57.32 | *** join/#brlcad Mandeep_Singh (~mandeep@101.60.206.224) |
| 16:59.59 | *** join/#brlcad amarjeet (~amarjeet@101.211.227.111) |
| 17:03.15 | Notify | 03BRL-CAD:starseeker * 68450 brlcad/branches/tcltk86/src/tclscripts/archer/Archer.tcl: tweak get_html_data - earlier change didn't work well. |
| 17:45.54 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 18:07.33 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 18:17.00 | Notify | 03BRL-CAD:brlcad * 68451 brlcad/trunk/src/libtclcad/tclcad_obj.c: nothing temporary about it after two years, remove dead comments |
| 18:19.54 | Notify | 03BRL-CAD:brlcad * 68452 (brlcad/trunk/src/libbrep/BBNode.cpp brlcad/trunk/src/libbrep/BRNode.cpp): the headers properly wrap themselves with BEGIN/END_DECLS, so don't need to manually wrap them here |
| 18:22.42 | starseeker | we appear to be making heavy use of an accidental propery of itcl3 in Archer that has not transitioned to itcl4 |
| 18:23.26 | starseeker | has put itcl3 in place in the 8.6 branch successfully, but system installs are going to provide 4 if they provide anything... |
| 18:24.46 | starseeker | wonders how large a rework of Archer we should accept before a) just using the bundled itcl3 always instead or b) starting to think about Qt... |
| 18:25.59 | starseeker | brlcad: I note the acknowledgements panel is still present in the About dialog in Archer - did you want to change that? |
| 18:26.27 | starseeker | minimally should be updated... |
| 18:27.21 | Stragus | makes "ewww" sounds at the mention of Qt |
| 18:27.42 | starseeker | <snort> how much experience do you have with Tk? |
| 18:28.04 | Stragus | None :), having trouble maintaining the Tk code? |
| 18:28.27 | starseeker | Stragus: less that than running into limits with what we can easily do in Tk |
| 18:28.41 | Stragus | That sounds like a problem |
| 18:28.56 | starseeker | it hasn't helped our usability much |
| 18:30.29 | *** join/#brlcad ickby (~stefan@x5d846937.dyn.telefonica.de) |
| 18:30.57 | Stragus | I can imagine. Perhaps an OpenGL-based GUI would integrate better with the OpenGL rendering... I have done a few things with mine: http://www.rayforce.net/glui002.png |
| 18:31.49 | Stragus | Qt would provide all the ready-to-use widget collection, but it has its own share of issues |
| 18:31.54 | starseeker | nods - that was/is one of the possibilities, but Qt gives us a lot of useful stuff we'd more or less have to hand-roll inOpenGL |
| 18:33.01 | starseeker | rather likes the look of nanovg |
| 18:33.48 | Stragus | Its rendering is poorly optimized. My screenshot above does 4000 fps |
| 18:34.16 | starseeker | blinks - wow. just bad execution on their part, or did they make some design tradeoffs? |
| 18:35.37 | Stragus | Bad design. It's immediate-style, instead of buffering, minimize state changes, uploading large buffers and as few GL Draw() calls as possible |
| 18:36.06 | starseeker | hmm |
| 18:36.40 | Stragus | Look at their screenshot, 44 fps. It's like a terrible joke |
| 18:37.05 | starseeker | heh - perhaps they were optimizing for interactivity on crappy hardware? |
| 18:37.33 | Stragus | No, everything that memononen guy writes is terrible for performance, serious design issues |
| 18:37.46 | Stragus | He comes up a lot in #opengl due to his fontstash and friends |
| 18:38.08 | starseeker | has found fontstash itself quite useful... |
| 18:38.17 | Stragus | Ah! :) |
| 18:38.28 | starseeker | granted, I'm not pushing any performance boundaries when I use it either |
| 18:39.14 | Stragus | Well, just keep that in mind when comparing 44 fps to 4000 fps |
| 18:39.49 | starseeker | Stragus: if you've looked at libdm at all, you know we've other other stuff to fix before that's going to be worrisome |
| 18:40.25 | starseeker | Stragus: if fontstash isn't very good, what's your recommended solution for text? |
| 18:41.23 | Stragus | Not sure actually, I wrote my own based on freetype |
| 18:41.40 | Stragus | really needs to put a lot of stuff on github or whatever |
| 18:42.35 | starseeker | what about fontstash is bad peformance wise? I knew nanovg was slow, but I've seen less about fontstash |
| 18:43.22 | Stragus | The hashing function and table is bad. It's querying freetype constantly for the kerning between characters. Oh, and there are actually errors in the spacing and kerning |
| 18:44.06 | starseeker | fontstash doesn't use freetype, unless something changed - doesn't it use stb_freetype? |
| 18:44.09 | Stragus | I don't remember what the actual GL rendering was... but it should all be buffered, batched, uploaded and drawn together |
| 18:44.38 | Stragus | Ah yes, there is #define in it to switch to freetype. If you don't use freetype, then there's no glyph hinting and other issues |
| 18:44.50 | Stragus | Glyph hinting is pretty important for small fonts |
| 18:45.12 | Stragus | With glyph hinting, tiny fonts are still readable: http://www.rayforce.net/glui001.png |
| 18:45.22 | starseeker | nods - knew it was simplistic, but plenty good enough compared to our old solutions.. |
| 18:46.29 | Stragus | (For screenshot, the sizes are in pixels, not font "points" or whatever) |
| 18:48.48 | starseeker | Stragus: check out our current font logic for the GLX backend: https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/libdm/dm-ogl.c#l238 |
| 18:49.36 | starseeker | Stragus: I think the more sophisticated OpenGL text solutions do do better with freetype - Sean's a fan of FTGL, which I think does better but was/is also more work to integrate |
| 18:49.39 | Stragus | Oh, X fonts :) |
| 18:50.34 | Stragus | I never really looked into ftgl, I know they have some interesting features |
| 18:51.25 | starseeker | Once we get a proper cross-platfom OpenGL backend in place we can start to get more sophisiticated, but right now any major libdm work has to take glx, wgl, X, and several others into consideration |
| 18:51.37 | Stragus | Large fonts also benefit from signed distance fields, I wrote code for that |
| 18:52.06 | starseeker | Stragus: heh - yeah, you'd probably achieve some fame on github if you were so inclined |
| 18:52.09 | Stragus | Just use freetype2 and be cross-platform, same results everywhere |
| 18:52.14 | starseeker | nods |
| 18:52.52 | starseeker | freetype has improved a *lot* in terms of ease of integration, one of the things that will really help when we switch |
| 18:53.23 | starseeker | wish their license was just a bit more liberal, but I think we're OK to use it |
| 18:53.50 | Stragus | If you think you might use my code, I think that would motivate me to clean up, provide demos, perhaps even... *shivers* documentation |
| 18:54.47 | starseeker | Stragus: well, right now our "cutting edge" libdm backend is using OpenSceneGraph to provide a cross platform API to give us an OpenGL canvas, and then we're using fontstash for cross platform text |
| 18:54.49 | Stragus | An OpenGL gui really has some serious advantages for GL-based CAD software |
| 18:54.57 | Stragus | Darn. |
| 18:56.00 | Notify | 03BRL-CAD:brlcad * 68453 brlcad/trunk/src/util/CMakeLists.txt: the tk apps need to specify their tcl/tk library deps. not necessarily coupled to X11 either (e.g., aqua) |
| 18:56.34 | starseeker | so if you have a lightweight wrapper library to initialize and interact with opengl and a fast/decent text rendering solution I'd be interested :-) |
| 18:56.50 | Notify | 03BRL-CAD:brlcad * 68454 brlcad/trunk/src/shapes/fence.h: use the decl wrappers from common |
| 18:57.25 | Stragus | Text, definitely so. For the OpenGL setup, I have always used GLFW everywhere, it's excellent. Or did you mean more than managing context/input? |
| 18:57.37 | starseeker | would prefer not to pull OSG along unless/until we're actually using the scenegraph, which requires quite a bit more libdm/libfb/mged work to do properly |
| 18:57.57 | Stragus | OSG is terrible. It does 110k malloc() calls to render a cube |
| 18:58.00 | starseeker | glfw would work if we could embed the OpenGL canvas it provides in a Tk context |
| 18:58.05 | starseeker | window rather |
| 18:58.27 | starseeker | last time I looked at glfw, it was assuming it always provides the window |
| 18:58.37 | Stragus | Indeed, I think that's the case |
| 18:58.50 | starseeker | that might be fairly simple to change - if so, it would sure be way lighter than OSG |
| 18:59.14 | starseeker | Stragus: is OGRE better than OSG performance wise, or do they make many of the same mistakes? |
| 18:59.21 | Stragus | Yes should be, I'm fairly familiar with the GLFW code |
| 18:59.32 | Stragus | Ogre is also very osbolete |
| 18:59.52 | Stragus | Seriously, why not use your own engine? |
| 18:59.53 | starseeker | Stragus: huh. Who are the new kids on the block? Or is implementation lagging behind theory? |
| 19:00.06 | starseeker | Stragus: 'cause we'd rather not write one ourselves? |
| 19:01.00 | starseeker | hunts up glfw - that sounds like a nice respite from rewriting Tcl/Tk CMake build code |
| 19:01.04 | Stragus | Well, it's not like you need shadow cascades, spherical harmonics or deffered lighting... Your needs are pretty light? |
| 19:01.11 | starseeker | correct |
| 19:01.38 | starseeker | although I'm not opposed to using fancy features once we get a proper scene set up... |
| 19:01.49 | Stragus | So it could take about as long writing good GL code than figuring out how to work with some engine that's potentially slow and/or poorly adapted and/or lacking features |
| 19:02.42 | starseeker | nods - that could very well be |
| 19:03.05 | starseeker | but the odds i would do a new one the "right" way are fairly low, at least for a first cut |
| 19:03.35 | Stragus | I think I have quite a bit of experience with GL if you ever have questions |
| 19:04.37 | starseeker | Stragus: ideally we'd want to integrate things like LoD (Hoppe's code dump of progressive mesh code make that even more interesting) |
| 19:04.58 | starseeker | give how big the models we work with can get, some sort of size management would really help |
| 19:05.15 | Stragus | I wrote this 3 years ago in spare time... I wanted to test my computational fluid dynamics then got distracted: http://www.rayforce.net/newproject024.png |
| 19:06.27 | starseeker | heh - nice! |
| 19:06.47 | Notify | 03BRL-CAD:brlcad * 68455 (brlcad/trunk/src/conv/step/BRLCADWrapper.h brlcad/trunk/src/libanalyze/find_subtracted_shapes.cpp and 9 others): remove the extern C wrappings as all our headers should now be properly wrapped for the caller |
| 19:07.41 | *** join/#brlcad ickby (~stefan@x5d846937.dyn.telefonica.de) |
| 19:08.50 | Stragus | For LODs, is it something you can just precompute? |
| 19:09.23 | starseeker | maybe... there are multiple options there |
| 19:09.33 | starseeker | NURBS models we might be able to re-tessellate on the fly |
| 19:09.42 | Stragus | I'm not sure how important a "smooth" choice of level of details really is. Done properly, one can't even see the transition points |
| 19:09.52 | starseeker | nods |
| 19:11.23 | starseeker | yeah, GLFW doesn't expose the context creation independent of the Window creation |
| 19:11.36 | starseeker | wonder how hard it is to extract the context part... |
| 19:11.39 | Stragus | Yes, but I think it could be hacked in |
| 19:14.37 | Stragus | And dreda is the maintainer, always answering questions in #glfw |
| 19:15.01 | starseeker | recalls asking long ago about the possibility, I think it was deemed a bit out of scope |
| 19:15.11 | Stragus | Ah :/ |
| 19:15.12 | starseeker | that would have been back around the togl work |
| 19:15.36 | starseeker | still, boiling the context subset of this might not be too hard |
| 19:15.48 | Stragus | nods |
| 19:16.13 | starseeker | question is whether it's worth it just to displace the OSG sources - that does work now, however cumbersom it might be |
| 19:18.05 | starseeker | If Tk provided an OpenGL widget worth anything I'd cheerfully make it the client's responsibility to supply an OpenGL context |
| 19:18.18 | Stragus | That's really a huge dependency, and just to create a GL context? |
| 19:18.44 | Stragus | I don't even know if OSG supports the creation of core contexts, debugging contexts, and so on |
| 19:18.50 | starseeker | at the moment - eventually we plan to use the scene features, but before we can do that some of MGED's basic assumptions need to be altered |
| 19:19.40 | Stragus | I really would *not* recommend OSG. I have had the displeasure of debugging something in OSG for Lee, I have looked under the hood |
| 19:20.25 | Stragus | The horror, the horror... It's like academia C++ pushed to 11 |
| 19:21.18 | starseeker | Stragus: well, I'll look at extracting the context bits out of glfw and see if they can replace what we're currently using OSG for |
| 19:21.30 | Stragus | Also using GL display lists, immediate mode, and so on. If you want to do anything modern, then forget it, it's not in OSG |
| 19:22.07 | Stragus | (110000 malloc() calls to render a cube, argh!) |
| 19:23.02 | starseeker | Stragus: bear in mind we do need a reasonable fallback mode if OpenGL is hozed on a computer for some reason - I'd be fine with making a a platform agnostic version of tinygl or extracting mesa's software-only rendering backend for that... |
| 19:23.40 | starseeker | more importantly though is we can't assume super-modern OpenGL features all the time - there has to be a reasonable "degraded" mode we can guarantee everywhere |
| 19:23.40 | Stragus | A fallback mode, meaning a GL 1.1 path? |
| 19:23.56 | starseeker | well, whatever can be usably implemented in software |
| 19:24.05 | starseeker | I think mesa may be up around 2, but I"m not sure |
| 19:24.08 | starseeker | haven't checked lately |
| 19:24.31 | Stragus | I think they implement GL 3.1 |
| 19:24.38 | starseeker | do they |
| 19:24.53 | starseeker | huh - I haven't been keeping track, that's further along than I thought |
| 19:25.37 | Stragus | GL 3.1 is pretty much modern GL, minus compute shaders and other goodies |
| 19:26.08 | starseeker | the question is whether their software-only mode can do that |
| 19:26.37 | Stragus | Yes, I think so. Anyhow, your needs are simple, so even writing ol' good GL 1.1 shouldn't be too hard |
| 19:26.42 | starseeker | nods |
| 19:27.01 | starseeker | we've suggested student projects in the past to take tinygl and make it more cross platform |
| 19:27.36 | Stragus | Last update in 2002, that's not a good sign |
| 19:27.50 | Stragus | "16 bit Z buffer. 16 bit RGB display. High speed dithering to paletted 8 bits if needed. High speed convertion to 24 or 32 bits" |
| 19:27.53 | Stragus | Okay, that's not good |
| 19:28.45 | starseeker | if we make an alterned version of the glfw wrapping API, we could probably put the key software rendering bits from mesa's swrat or maybe softpipe behind that API |
| 19:30.03 | Stragus | Does it really come up often that people run CAD software on machines without any GL? Even Windows or Linux without drivers provide at least GL 1.1 |
| 19:30.06 | Stragus | (in software) |
| 19:31.54 | starseeker | it does sometimes happen that the drivers will temporarily be in a non-functional state (after an update) or someone tries to display across a network interface and things get interesting |
| 19:32.47 | Stragus | And when you want to be bullet-proof even in such cases, okay |
| 19:32.54 | Stragus | And * you want |
| 19:32.57 | starseeker | that usually happens when there are tight deadlines people are trying to satisfy (I think there's some sort of universal law about that) |
| 19:33.03 | starseeker | so, yeah :-) |
| 19:33.08 | Stragus | Eheh :), got it |
| 19:33.31 | starseeker | but you're right, GL 1.1 would do what we need |
| 19:34.01 | starseeker | tinygl may not be very impressive, but it's better than the raw X backend (which can only do wireframe - no shaded mode) |
| 19:34.25 | starseeker | not being able to assume shaded drawing for your scene interface is a bummer |
| 19:34.41 | Stragus | Mesa's LLVM can generate SSE/AVX code and be somewhat-kind-of-usable |
| 19:35.05 | starseeker | that would require the llvm backend though |
| 19:35.34 | starseeker | we may get there someday if we incorproate support for Open Shading Language, but it's an even bigger dependency than OSG if I'm not mistaken |
| 19:35.57 | Stragus | Open Shading Language?... Why not GL's GLSL? |
| 19:36.13 | starseeker | OSL is for raytracers |
| 19:36.23 | Stragus | Oh. Interesting |
| 19:37.32 | starseeker | ah, this looks like an active ftgl fork: https://github.com/ulrichard/ftgl |
| 19:38.05 | starseeker | few other forks with changes |
| 19:38.24 | Stragus | wants to see the GL rendering code |
| 19:39.04 | starseeker | not sure where that'd be tucked away - Sean probably knows |
| 19:40.10 | Stragus | Technically, my font manager doesn't depend on GL, and rather delegates the rendering to an abstract "renderer" which does, doing the buffering and batching |
| 19:40.45 | Stragus | So you can switch the renderer at will. ftgl may work the same way |
| 19:40.49 | starseeker | nods - I seem to remember something about that for fontstash as well - opengl was just the "output" form used for the rendering |
| 19:40.58 | Stragus | Right |
| 19:41.08 | *** join/#brlcad ickby_ (~stefan@x5d846937.dyn.telefonica.de) |
| 19:41.44 | starseeker | ugh - ftgl has a whole subdirectory for MSVC builds? |
| 19:41.56 | Stragus | Also, fontstash is not flexible enough to do things like two-channel post-processing with custom spacing, in order to do outlined text |
| 19:42.02 | starseeker | nods |
| 19:42.27 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 19:42.31 | starseeker | ew - no project with a decent CMake build should need checked-in visual studio project files |
| 19:43.07 | Stragus | That's another reason I don't put anything on github. Can't stand all build systems, I write Makefiles or even just bash scripts |
| 19:43.40 | starseeker | nods - github works find for that though - you just check in what you want and let someone else make the build system they like |
| 19:43.53 | Stragus | I frequently need to do things like compiling the same .c or .cu file multiple times with different options, and it's always a nightmare with build systems |
| 19:43.58 | starseeker | has a bunch of forks/projects that are CMake-ifications of other projects |
| 19:44.02 | Stragus | Ah, cool |
| 19:44.35 | starseeker | new one just this week, in fact: https://github.com/starseeker/unifdef |
| 19:45.04 | Stragus | Eh, neat |
| 19:45.32 | starseeker | they give you the "forked from" link so you can always reference the original project |
| 19:46.59 | starseeker | my SuperLU CMake build even got a user - I've gotten several patches back updating to the latest version. |
| 19:47.25 | starseeker | someday I'll finish up my Meshlab conversion - it hasn't ticked me off lately, so I've kinda stalled |
| 19:47.51 | Stragus | You are a CMake fan then :) |
| 19:48.18 | starseeker | I'm a fan of what it allows you to do - one build system for OSX, Linux, BSD, and MSVC |
| 19:48.40 | starseeker | I'm not crazy about their syntax - I think they should have gone with lua or some such rather than inventing their own language |
| 19:48.51 | Stragus | It just seemed so complicated to do basic things like "compile this, run that, *then* compile X 10 times with these options" |
| 19:49.08 | starseeker | but compared to sh+m4+automake+autoconf+... it's awesome |
| 19:49.41 | starseeker | Stragus: yeah, the latter bit does conflict with their mental model of build targets |
| 19:50.07 | Stragus | Exactly |
| 19:50.45 | starseeker | usually there are work-arounds that are simpler than trying to maintain and sync multiple build systems across different platforms though - we did that pre-CMake, and it sucked |
| 19:50.47 | Stragus | I want to compile my CUDA pipelines for all variety of CUDA hardware, and for all runtime options for the pipeline, which can be a total of 200 times |
| 19:51.59 | starseeker | Stragus: Couple of possible approaches... I'd probably write a CMake script to automatically set that up in the build directory. |
| 19:52.32 | starseeker | configure_file and execute_process can be used to do quite a lot, if you really need to |
| 19:52.55 | Stragus | I'll try to motivate me to try again one day... :) |
| 19:53.02 | starseeker | heh |
| 19:53.44 | starseeker | I don't recommend CMake for all situations, certainly - but when you want to be trivially portable to Windows+MSVC, it just makes life a lot simpler |
| 19:54.19 | starseeker | You can do most of your work on a Real OS, then check things on Windows just by pulling the updates, configuring and building |
| 19:54.31 | Stragus | I'm not concerned by MSVC, I tend to write C gnu99 |
| 19:54.40 | Stragus | (which compiles with GCC, clang and ICC) |
| 19:54.43 | starseeker | no updating VS project files and hoping the bugs aren't too bad because nobody else has checked in 6 months |
| 19:54.51 | Stragus | Eheh |
| 19:55.11 | starseeker | nods - unfortuantely, we have no choice but to pay attention to MSVC |
| 19:55.23 | *** join/#brlcad yorik (~yorik@189-46-38-150.dsl.telesp.net.br) |
| 19:55.53 | starseeker | several times we've had to "port" possible third party libs over to MSVC ourselves, because were the first in the open source community to actually care |
| 19:56.17 | Stragus | I'm actually surprised you do |
| 19:56.27 | Stragus | What's wrong with mingw64, the Intel compiler? |
| 19:57.31 | starseeker | we haven't yet managed to fully port to mingw64, and I've had fairly mixed luck with it over the years - mainly getting it set up correctly. It's still quite easy to do that wrong |
| 19:57.49 | Stragus | Okay, that is surprising |
| 19:58.07 | starseeker | the Intel compiler is usually pay-to-play - I think there may be a program now for open source projects, but I don't know about on Windows |
| 19:59.01 | starseeker | we really should get mingw64 working... I've been half hoping someone would take Qt Creator, the new clang Windows porting work, and whatever bits from the mingw setup are needed to make a true "plug and play" open source C/C++ development ala MSVC |
| 19:59.18 | Stragus | Not sure. I know SURVICE wanted some code to compile on Windows without expecting people to use mingw64, because people want software they pay for, and apparently ICC was the best solution |
| 19:59.44 | starseeker | it's a good compiler |
| 19:59.52 | starseeker | or at last, that's what I've heard about it |
| 20:00.15 | Stragus | It's supposed to be good at auto-vectorization. I do my own SSE/AVX, and GCC comes up on top by 2% or so |
| 20:00.22 | starseeker | but the Visual Studio Community edition can be used for open source projects and is both free and simple to get working |
| 20:01.22 | starseeker | ideally, we would be able to build anywhere someone wanted to build - mingw is actually our most glaring defect in that regard |
| 20:01.53 | Stragus | I agree, it is very surprising. It's the same old good GCC! |
| 20:02.26 | Stragus | I never had any trouble with my code and mingw64 |
| 20:11.40 | starseeker | Stragus: well, if you're interested you can grab the latest trunk and see if it builds |
| 20:13.46 | *** join/#brlcad ickby_ (~stefan@x5d846937.dyn.telefonica.de) |
| 20:19.43 | Notify | 03BRL-CAD:starseeker * 68456 brlcad/branches/tcltk86/src/other/CMakeLists.txt: Note the itcl4 issue Archer is having, and provide relevant info. |
| 20:24.07 | *** join/#brlcad ickby (~stefan@x5d846937.dyn.telefonica.de) |
| 20:31.29 | Notify | 03BRL-CAD:brlcad * 68457 brlcad/trunk/AUTHORS: note the 2013 doc camp team (save for sean and cliff which already have core status) under documentation. |
| 20:51.15 | Notify | 03BRL-CAD:brlcad * 68458 brlcad/trunk/src/libged/gdiff.c: remove dead code |
| 20:58.20 | *** join/#brlcad ickby (~stefan@x5d846937.dyn.telefonica.de) |
| 21:16.20 | *** join/#brlcad ickby_ (~stefan@x5d846937.dyn.telefonica.de) |
| 21:29.50 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 21:45.52 | Notify | 03BRL-CAD:brlcad * 68459 brlcad/trunk/NEWS: jon added a -f vertex fuse option to obj-g that fuses verticies within a given tolerance. this helps the solidity detection work but is slower (hence off by default). |
| 21:45.54 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 21:50.32 | Notify | 03BRL-CAD:brlcad * 68460 brlcad/trunk/NEWS: keith fixed the bb command volume reporting, which was returning mm^3 instead of the localized units. also increased precision beyond one digit past the decimal, reported by a user having problems with sub-inch boxes. |
| 22:06.17 | Notify | 03BRL-CAD:brlcad * 68461 brlcad/trunk/TODO: note where things left off with the joint articulation work (both the old system and the new joint objects) from the big bullet branch merge (r62451) |
| 22:13.15 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 22:14.49 | Notify | 03BRL-CAD:brlcad * 68462 brlcad/trunk/NEWS: cliff made fast4-g import CCONE1 even when they have an illegal thickness. previously discarded them, but now imports as volume cones. (r61433) |
| 22:18.09 | Notify | 03BRL-CAD:brlcad * 68463 brlcad/trunk/NEWS: bob fixed (in r61402) the fork+exec method being used on windows in rtwizard where edge drawing and ghosting were not working. |
| 22:20.13 | Notify | 03BRL-CAD:brlcad * 68464 brlcad/trunk/TODO: we're all in, need brep support |
| 22:29.01 | Notify | 03BRL-CAD:brlcad * 68465 brlcad/trunk/NEWS: keith fixed the face validation check so that it no longer tests the normal against the distance tol, instead checking the dot product against the parallel tol. this improved ray tracing and bounding boxes of really tiny triangles with edges at/near the distance tol. (r61337) |
| 22:32.40 | Notify | 03BRL-CAD:brlcad * 68466 brlcad/trunk/NEWS: keith added conversion timings output to the step importer, telling how long it takes to load and convert |
| 22:35.26 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 22:38.44 | *** join/#brlcad merzo (~merzo@232-36-201-46.pool.ukrtel.net) |
| 22:41.47 | Notify | 03BRL-CAD:brlcad * 68467 brlcad/trunk/NEWS: cliff improved the search command's manual page with a list of the -params parameters that can be specified. |
| 22:42.01 | Notify | 03BRL-CAD:n_reed * 68468 (brlcad/branches/brep-debug/doc/docbook/system/implementation/en/CMakeLists.txt brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml): changes to support pdf export |
| 22:59.39 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:10.19 | Notify | 03BRL-CAD:starseeker * 68469 brlcad/trunk/NEWS: Note upgrade to libpng 1.6.23 |
| 23:59.13 | Notify | 03BRL-CAD:starseeker * 68470 (brlcad/branches/qtged/src/qged/CMakeLists.txt brlcad/branches/qtged/src/qged/cadresources.qrc): Pull in some of the appleseed resources for Qt UI customization. Doesn't quite apply cleanly to qged (for one thing they're using a preprocessing trick on their stylesheets) but it looks like it may have some helpful hints. |
