Welcome Ștefan! On Oct 7, 2014, at 8:17 AM, Ștefan-Gabriel Mirea wrote:
> My name is Stefan Mirea, I study Automatic Control and Computers at > Politehnica University of Bucharest and I'd like to contribute to > BRL-CAD as a software developer. I read some of the documentation and > Wiki articles and I also downloaded and built BRL-CAD. Might I also suggest our dev book: http://en.flossmanuals.net/contributors-guide-to-brl-cad/ Jacob made a rough PDF version here: http://brlcad.org/~maths22/HACKING_BRL-CAD.pdf > I think that fixing a bug would be a good start, so I chose the second > bug in the BUGS file (the first one is about Windows and I am a Linux > user). Excellent place to start. If you want more info about any of those bugs, there is often additional notes in the commit messages. Running "svn annotate BUGS" will show what version a line was last changed (e.g., when it was added) and that version can be looked up in the "svn log BUGS" output. Sometimes it's not helpful, sometimes it has very specific information helpful for debugging. > I looked into the source code and I found that the cp pointer in > txt_render() is used to access memory from tp->tx_mp->buf or > tp->tx_binunifp->u.uint8 to get the pixel colors, but it is > dereferenced without verifying whether the offset exceeds the buffer > size. txt_load_datasource() in sh_text.c checks if the real size of > the image file matches the one corresponding to the given dimensions > (and it does a good job), but will only produce a warning. Sounds like an accurate analysis of the code. > I think that the best fix would be rendering a specific color (such as > white) in the regions of the surface that would require "out of image" > access. If the color of just one pixel is needed (when > (dx == 0 && dy == 0) - line 304 in sh_text.c), then txt_render() > should simply set r, g, and b to that default color. Otherwise, when > the function would normally compute the weighted average of the cells, > I would only check if the furthest needed cell in the buffer exceeds > its size (without looping through the neighboring pixels). Interesting idea. I hadn't actually considered doing anything other than aborting. Your idea makes me wonder if instead of a specific color, how about wrapping the image coordinates? Basically modulo the width and/or height so it stays within the texture grid but can be indexed with literally any coordinate. Really any solution is better than crashing, so I'm not really apposed to anything. ;-) I suggest trying your idea or my idea and seeing how it actually works. BRL-CAD's texture mapping system is very primitive with plenty of room for improvement. We still don't even have arbitrary uv-mapping (it'd be a somewhat advanced project) or procedural textures (also an advanced topic). > I need your feedback concerning my suggestions, as this would be my > first contribution to an open source project. That's totally awesome. Feel free to also join our IRC channel if you want to chat while you work or bounce questions. Cheers! Sean ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
