| 04:09.54 | brlcad | hmm, that was |
| 04:10.11 | brlcad | a bit slowly |
| 04:10.23 | brlcad | presented for my taste |
| 04:10.31 | brlcad | arrr |
| 04:26.38 | Maloeran | Yes, the guy didn't seem very fast |
| 04:26.57 | Maloeran | But he actually picked my curiosity. As far as I can see, you can not have continuity with bezier triangles |
| 04:29.25 | Maloeran | Unless of course the two triangles have the same size exactly, which is... not very practical |
| 04:30.26 | Maloeran | I need to look over my curved facets again, it has been like an year since I wrote that and got attracted by more shiny problems |
| 04:47.32 | brlcad | it's an interesting problem, but seems like a rather limited utility domain |
| 04:48.14 | Maloeran | Not if the continuity is preserved for any mesh of triangles, if it's flexible and fast |
| 04:48.17 | brlcad | i mean perhaps if it were ubiquitous and implemented in hardware, esposed by opengl 4.0 or something, etc |
| 04:48.24 | Maloeran | Then you save a whole lot of memory to represent, let's say, an apple |
| 04:49.27 | brlcad | i mean topologically and representation wise, it doesn't buy you much over a nurbs |
| 04:49.39 | brlcad | other than the potential to evaluate lower order |
| 04:50.00 | Maloeran | Oh, but nurbs are horribly costly to intersect |
| 04:50.11 | brlcad | that's what I mean |
| 04:50.18 | Maloeran | The point is to have some very simple curved facets, as simple as they can be, which are very fast to intersect |
| 04:50.21 | brlcad | it's lower order, so considerably faster |
| 04:51.39 | Maloeran | Yes... but typical nurbs are still rather expensive, even low order ones |
| 04:52.13 | Maloeran | My idea is rather simple, I think we'll go over that tomorrow afternoon |
| 04:52.33 | brlcad | if you can't go from implicit or nurbs to these bezier triangles or whatever you want to call them, faithfully.. |
| 04:53.15 | Maloeran | I'm thinking CSG -> curved facets could be really nice |
| 04:53.52 | Maloeran | or high order nurbs -> curved facets |
| 04:54.04 | Maloeran | I don't believe much in transforming triangles into curved facets |
| 04:54.18 | brlcad | i wasn't disputing that nurbs are expensive, I was saying that topologically and representation wise, it doesn't buy you much other than that evaluation diff |
| 04:54.30 | Maloeran | Right |
| 04:55.39 | brlcad | i'm sure there's probably some tradeoff difference there as well depending on how many curvies you'd need to faithfully represent the equivalent patch/implicit |
| 04:56.30 | brlcad | curvies, I like that |
| 04:56.34 | Maloeran | Quite true. What I'm thinking is that we could reach better accuracy, performance and memory use with such curved facets rather than triangles |
| 04:56.46 | Maloeran | For some surfaces anyway |
| 04:56.53 | brlcad | yeah, that would be nice |
| 04:57.10 | brlcad | though I'm curious about a couple of the papers tomorrow regarding fast nurbs evaluation |
| 04:57.29 | Maloeran | I briefly shared some theory with Lee and Erik last month, but apparently, I'm not supposed to work on this stuff before all the other requirements are met |
| 04:57.48 | brlcad | you can work on whatever you want |
| 04:57.51 | brlcad | just not on the clock :) |
| 04:57.53 | Maloeran | Yes, let's hope it's better than what's presently on the internet |
| 04:58.06 | Maloeran | Oh, true :) |
| 04:59.30 | brlcad | "not supposed to work on XXX" sometimes also just means don't talk about XXX while working too ;) |
| 05:08.57 | Maloeran | *nods* I'm getting the idea :) |
| 07:17.54 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 14:45.44 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 17:26.10 | *** join/#brlcad b0ef (n=b0ef@062016141085.customer.alfanett.no) |
| 18:45.21 | *** join/#brlcad clock_ (i=clock@84-72-62-209.dclient.hispeed.ch) |
| 20:32.17 | *** join/#brlcad Twingy (n=justin@c-69-250-236-111.hsd1.md.comcast.net) |