Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The SQLite R*Tree Module

sqlite.org

Post reply on HN
Print view View original

11–17 of 17 posts

Re: The SQLite R*Tree Module

#11

Post by bob1029 »

phaedrus wrote: post #10
bob1029 wrote: post #5

I have started to play around with building a software rasterizer from scratch, and I am wondering if this might be something that I could potentially leverage to cheat at some of the math problems. The document mentions CAD, but I am not sure if the performance is such that real-time (i.e. 30+fps) queries would be feasible over meaningful datasets. Does anyone have any experience directly using SQL for this sort of…

You might have some success using hand-coded routines for the last / hardest-working portion of the rasterizer, and just use SQLite to translate data from a format produced by the front-end to a format that matches the back-end. I'm interested in relational programming for 3D meshes. For example what if we could use the form of a query to write a routine that splits a 3D mesh (creating new triangles at the boundary?)

The mesh manipulation is what interests me as well. I feel like SQL allows for a unique opportunity to explore solutions that would otherwise be impractical/difficult to experiment with using hand-coded imperative methods.

Re: The SQLite R*Tree Module

#12

Post by vlovich123 »

jjmod wrote: post #7
bob1029 wrote: post #5

I have started to play around with building a software rasterizer from scratch, and I am wondering if this might be something that I could potentially leverage to cheat at some of the math problems. The document mentions CAD, but I am not sure if the performance is such that real-time (i.e. 30+fps) queries would be feasible over meaningful datasets. Does anyone have any experience directly using SQL for this sort of…

It might be feasible if you use sqlite's in-memory feature, because hitting the disk on each query is way too slow for a real-time application. Why not just use an r-tree library for the language you're using? It'll be faster and easier to work with. Since scene data is usually hierarchial, sql doesn't seem like a great choice for storing it

Page cache and SQLite cache means you don’t actually end up hitting the disk usually. Also SSDs are pretty fast and NVMEs more so.

Maybe when you first start or access a new piece of data for the first time you maybe get a hiccup (maybe not - always profile to figure out how your specific application performs). If hiccups like that actually manifest, a nice way to solve that would be to attach the on-disk DB to the in-memory one, copy everything over (and maybe detach). If that DB is ever mutable at runtime, just copy the changes back in a background transaction to the on-disk DB (in this case I wouldn’t detach probably). This way you still get the persistence of the disk with the performance of RAM.

Re: The SQLite R*Tree Module

#13

Post by [deleted] »

bob1029 wrote: post #5

I have started to play around with building a software rasterizer from scratch, and I am wondering if this might be something that I could potentially leverage to cheat at some of the math problems. The document mentions CAD, but I am not sure if the performance is such that real-time (i.e. 30+fps) queries would be feasible over meaningful datasets. Does anyone have any experience directly using SQL for this sort of…

[deleted]

Re: The SQLite R*Tree Module

#14

Post by pdpi »

vlovich123 wrote: post #12
jjmod wrote: post #7

Earlier quoted context omitted.

It might be feasible if you use sqlite's in-memory feature, because hitting the disk on each query is way too slow for a real-time application. Why not just use an r-tree library for the language you're using? It'll be faster and easier to work with. Since scene data is usually hierarchial, sql doesn't seem like a great choice for storing it

Page cache and SQLite cache means you don’t actually end up hitting the disk usually. Also SSDs are pretty fast and NVMEs more so. Maybe when you first start or access a new piece of data for the first time you maybe get a hiccup (maybe not - always profile to figure out how your specific application performs). If hiccups like that actually manifest, a nice way to solve that would be to attach the on-disk DB to the i…

Graphics are a notorious case of CPU-bound applications. Adding IO boundedness to the equation seems like a bad idea.

I’m not saying it can’t be done, or that it can’t be fast. But it’s very much against the grain and needs more justification Than “NVMe is fast”

Re: The SQLite R*Tree Module

#16

Post by daliusd »

bob1029 wrote: post #5

I have started to play around with building a software rasterizer from scratch, and I am wondering if this might be something that I could potentially leverage to cheat at some of the math problems. The document mentions CAD, but I am not sure if the performance is such that real-time (i.e. 30+fps) queries would be feasible over meaningful datasets. Does anyone have any experience directly using SQL for this sort of…

https://www.sqlite.org/famous.html - there is at least one CAD company ;)

Re: The SQLite R*Tree Module

#17

Post by centimeter »

hagibborim wrote: post #4
centimeter wrote: post #2

I love SQLite's software model (embeddable library rather than a separate binary), but I often sorely miss the rich data model provided by postgres. I miss things like strong type checking, special types to represent times/coordinates/etc., and advanced index types like GiST indices.

How close does DuckDB get to fulfilling your needs?

Doesn’t look like it has rich types or advanced indices.
Post reply on HN