| 01:40.53 | pra5ad | yay! text renderer works |
| 01:41.09 | *** join/#brlcad maccam912 (n=470a7f52@bz.bzflag.bz) |
| 01:41.19 | maccam912 | is anybody here? I have a question |
| 01:41.44 | maccam912 | I will ask anyway |
| 01:42.05 | maccam912 | I am running Windows XP and have finally figured out how to compile it and install with CYGWIN |
| 01:42.15 | maccam912 | I am trying to start mged |
| 01:42.43 | maccam912 | and when I click on it it said that it was looking for some .dll's so I copy pasted them from cygwin install folder |
| 01:43.12 | maccam912 | they were all of the ones I was looking for, so I copy pasted them all from cygwin to the mged directory |
| 01:44.11 | maccam912 | then when I click on it it says 'Initializing and backgrounding, please wait...' so I wait, then it closes without me doing anyting after a couple of seconds |
| 01:44.34 | maccam912 | I installed it on linux, but It doesn't even open up on there |
| 01:44.56 | maccam912 | it is 7.6.6 if that matters |
| 01:45.04 | maccam912 | waiting for a reply... |
| 01:53.33 | *** join/#brlcad tegtmeye (n=tegtmeye@pool-70-17-225-27.balt.east.verizon.net) |
| 01:55.03 | maccam912 | hey |
| 01:55.10 | maccam912 | tegtmeye |
| 01:55.34 | maccam912 | are you there tegtmeye |
| 01:57.16 | maccam912 | ok, i have mged open, but when I try to do something |
| 01:57.46 | maccam912 | it says "no database has been opened |
| 01:57.49 | maccam912 | " |
| 02:05.06 | ``Erik | heh |
| 02:08.51 | pra5ad | what was the issue with a close-to-0 zNear plane? |
| 02:11.39 | ``Erik | Z buffer is logarithmically scaled against the znear, so as you make the znear smaller, you lose z precision further out |
| 02:11.45 | ``Erik | then you get overlap artifacts |
| 02:12.24 | ``Erik | http://sjbaker.org/steve/omniv/love_your_z_buffer.html <-- steve baker wrote a bit on it |
| 02:18.16 | pra5ad | so whats the work around |
| 02:18.41 | ``Erik | you should probably read everything at http://sjbaker.org/steve/omniv/index.html , just think some and don't blindly believe everything he says... he knows his shit, but I disagree with him on a couple minor points :) |
| 02:18.49 | ``Erik | the workaround is to put the z as far away as possible |
| 02:19.19 | ``Erik | another workaround is to do multipass... draw everything with a znear of 1, then draw everything close (again) with a znear of .1 and a zfar of 1, or something |
| 02:31.22 | pra5ad | these articles seem .. old |
| 02:33.18 | ``Erik | some of 'em are a bit old, but little has changed, I think |
| 02:41.17 | pra5ad | xenogears time |
| 02:42.52 | ``Erik | http://sjbaker.org/humor/mkI_telephone.html *giggle* |
| 05:18.43 | *** join/#brlcad CIA-6 (i=cia@flapjack.navi.cx) |
| 05:26.28 | *** join/#brlcad Maloeran (n=alexis@modemcable065.3-83-70.mc.videotron.ca) |
| 06:16.34 | *** join/#brlcad AchiestDragon (n=dave@whipy.demon.co.uk) [NETSPLIT VICTIM] |
| 06:16.34 | *** join/#brlcad joevalleyfield (n=joevalle@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 06:16.34 | *** join/#brlcad archivist_ (n=archivis@host217-35-76-52.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 06:17.33 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 06:17.33 | *** topic/#brlcad is http://brlcad.org/ || BRL-CAD is now Free Software! || 7.6.6 to be released by the 15th! |
| 06:17.33 | *** join/#brlcad BZBot (n=supybot@bz.bzflag.bz) |
| 06:17.41 | *** join/#brlcad brlcad__ (n=sean@bz.bzflag.bz) |
| 06:24.56 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/TODO: |
| 06:24.57 | CIA-6 | BRL-CAD: updates for the next two release iterations. for next release: start of windows |
| 06:24.57 | CIA-6 | BRL-CAD: merging, mingw build, clone, tracker, geometry examples. for release after, |
| 06:24.57 | CIA-6 | BRL-CAD: run-time path identification completion, autogen.sh, sf.net tracker scripts. |
| 06:26.07 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/TODO: write .g in-memory transfer example (tegt needs) |
| 06:32.37 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/rt/ (main.c opt.c): use 0.0 as the 'default' aspect ratio to represent unset. catch a negative aspect ratio as an error. a 'default'/unset aspect ratio will get adjusted to be the image dimensions ratio. |
| 06:36.09 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/NEWS: |
| 06:36.09 | CIA-6 | BRL-CAD: raytracers use image size for default aspect ratio now instead of just 1.0 so |
| 06:36.09 | CIA-6 | BRL-CAD: that model space aspect is maintained and preferred over the image space aspect. |
| 06:36.09 | CIA-6 | BRL-CAD: stops making the dang squished pics when you specify -n/-w options to any of the |
| 06:36.09 | CIA-6 | BRL-CAD: raytracers |
| 06:41.23 | *** join/#brlcad archivist_3 (n=archivis@host217-35-76-52.in-addr.btopenworld.com) |
| 06:48.44 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/TODO: use environ for run-time path tracing lookups |
| 06:53.14 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/TODO: investigate performance impact of using sched_setaffinity and/or pthread_attr_setaffinity_np for linux threading affinity in librt |
| 07:04.48 | *** join/#brlcad Twingy (n=justin@pcp0011649600pcs.aberdn01.md.comcast.net) [NETSPLIT VICTIM] |
| 07:43.37 | *** join/#brlcad Maloeran (n=alexis@modemcable065.3-83-70.mc.videotron.ca) |
| 07:57.15 | *** join/#brlcad clock_ (n=clock@84-72-62-151.dclient.hispeed.ch) |
| 08:11.00 | *** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) |
| 08:11.00 | *** mode/#brlcad [+o brlcad] by ChanServ |
| 09:03.11 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 10:30.04 | *** join/#brlcad pier (n=d9850efc@bz.bzflag.bz) |
| 11:21.35 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) |
| 16:35.57 | clock_ | hi |
| 16:43.18 | brlcad | hey :) |
| 16:47.38 | clock_ | I found out that free software project structure is identical to a structure of a gang |
| 16:47.47 | clock_ | With the only exception, and that is evil polarity |
| 16:48.14 | clock_ | fits really excellent |
| 16:48.50 | clock_ | Actually not only free sw, but also User Controlled Technology |
| 16:53.35 | brlcad | sounds about right |
| 16:54.04 | brlcad | also known as and managed as a meritocracy in most cases |
| 16:54.31 | brlcad | where merit is the driving force of who's in charge, who gets overthrown (stabbed, forked, whatever) |
| 16:54.44 | brlcad | and the hierarchy of developers and contributors |
| 16:59.39 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/librt/shoot.c: only test the debug flags extensively if something in run-time debug is enabled |
| 17:00.27 | clock_ | merit driving force? Can you explain? |
| 17:02.22 | brlcad | ~dict merit |
| 17:02.55 | brlcad | you have a value as determined by your peers, others involved with the project |
| 17:03.07 | clock_ | OK now I almost understand |
| 17:03.08 | brlcad | the more and better work you do, the more merit you have |
| 17:03.23 | brlcad | those with high merit are in charge |
| 17:03.57 | brlcad | having history with a package or starting a package gets you high merit, which usually explains why original devs tend to stay in charge |
| 17:04.21 | brlcad | but they can be overthrown or replaced if others do more and work harder/better |
| 17:05.14 | brlcad | simple example, you already have more merit than an average person who enters the channel and asks for help |
| 17:05.46 | brlcad | simply because you're already an existing user who has used the package, has expressed an interest, has contributed to the project, etc |
| 17:07.30 | brlcad | it's not an artificially imposed structure like you working for a boss at work who might be an idiot. you are valued by your partipation, insight, contributions, etc |
| 17:09.09 | brlcad | in most open source projects, you become a developer not by applying for the job/role of developer -- you become a developer by earning the respect of the other existing developers through useful contributions |
| 17:09.26 | clock_ | that's what fascinates |
| 17:09.27 | clock_ | me |
| 17:10.19 | clock_ | skater also doesn't apply for a skater job, but has to skate and the better he skates, the bigger respect the others have. |
| 17:10.41 | brlcad | yep |
| 17:11.08 | clock_ | do you have gangs in the US? |
| 17:11.21 | brlcad | and if/when he becomes good enough or better than others, people start listening, paying attention, respecting his wants and options |
| 17:11.24 | clock_ | or where you live? |
| 17:11.24 | brlcad | heh, of course |
| 17:11.38 | clock_ | are they persistent and difficult to eradicate? |
| 17:11.39 | brlcad | there are gangs everywhere |
| 17:12.01 | brlcad | mostly inner-city in the big cities |
| 17:12.27 | brlcad | young kids usually |
| 17:12.38 | clock_ | almost invariably doing crime, right? |
| 17:12.40 | clock_ | how young? |
| 17:12.57 | brlcad | mostly teenagers |
| 17:13.07 | brlcad | some are crime gangs, some aren't |
| 17:13.23 | clock_ | who do those noncrime gangs do? |
| 17:13.33 | clock_ | teenager=13 to 19 right? |
| 17:13.43 | brlcad | yeah, pretty much |
| 17:13.44 | clock_ | were z-boys gang as well? |
| 17:13.56 | brlcad | i'm sure there are others outside that age range |
| 17:14.14 | clock_ | toddlers with machine guns ;-) |
| 17:15.00 | clock_ | have you ever been in any gang? |
| 17:15.01 | brlcad | z-boys was a team |
| 17:15.04 | brlcad | they competed |
| 17:15.20 | clock_ | against other teams right? |
| 17:15.21 | brlcad | but probably a fine line as to whether they behaved as a gang too |
| 17:15.25 | brlcad | ~dict gang |
| 17:16.17 | brlcad | lots of definitions (2 of 8) |
| 17:16.25 | brlcad | merriam-webster's is better: |
| 17:16.27 | brlcad | (1) : a group of persons working together (2) : a group of persons working to unlawful or antisocial ends; especially : a band of antisocial adolescents |
| 17:16.57 | brlcad | 2: a group of persons having informal and usually close social relations |
| 17:17.07 | clock_ | how can be adolescents antisocial? |
| 17:17.27 | brlcad | so doesn't have to be illegal, just have to have be a close group of people |
| 17:18.04 | brlcad | just frequently do engage in illegal activity sometimes |
| 17:18.04 | brlcad | depends on the people |
| 17:18.25 | clock_ | and otherwise drink and smoke weed |
| 17:18.33 | clock_ | or what can "classical" gang do? |
| 17:18.43 | brlcad | i would hope the don't drink week |
| 17:18.45 | clock_ | chase girls |
| 17:18.46 | brlcad | *weed |
| 17:19.22 | brlcad | most adolescents chase mates :) |
| 18:40.49 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/rt/do.c: make sure pixmap is null before wiping it out. instead of setting all the elements to zero, save cpu cycles and just request a bu_calloc... |
| 18:56.35 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/src/rt/worker.c: (log message trimmed) |
| 18:56.36 | CIA-6 | BRL-CAD: rewrite do_pixel() for a 30% performance enhancement on an model-less scene. |
| 18:56.36 | CIA-6 | BRL-CAD: this results in a savings of 5-30% time depending on model complexity/size. the |
| 18:56.36 | CIA-6 | BRL-CAD: performance is gained by removing some rediculous memory copying into |
| 18:56.36 | CIA-6 | BRL-CAD: temporaries and optimizing away several divisions and modulos. the main loop is |
| 18:56.36 | CIA-6 | BRL-CAD: also unrolled one iteration since the default case does not involve |
| 18:56.38 | CIA-6 | BRL-CAD: hypersampling. also rework the logic on testing whether a pixmap (previous |
| 19:04.44 | Maloeran | Have we met last friday, Sean? I didn't catch the name of everybody ( Alexis at Survice's place ) |
| 19:05.16 | brlcad | No, I couldn't make it over to SURVICE |
| 19:05.48 | Maloeran | Ah, right |
| 19:06.02 | brlcad | heard that you were there though |
| 19:06.57 | *** join/#brlcad pier (n=pier@151.56.213.59) |
| 19:07.17 | brlcad | ciao pier |
| 19:09.35 | pier | salve |
| 19:09.52 | pier | how are you? |
| 19:16.25 | brlcad | going good |
| 19:24.27 | pier | I post a request this moning |
| 19:24.30 | pier | http://sourceforge.net/tracker/index.php?func=detail&aid=1387937&group_id=105292&atid=640805 |
| 19:25.08 | pier | of course I am trying to get some result before asking for help |
| 19:25.24 | pier | reading the source code |
| 19:26.02 | brlcad | pier: yes, I read that |
| 19:28.25 | pier | but I think I'll have to dig first in the header files to get an idea on how the various functions called in g-dxf code work |
| 19:29.03 | pier | not easy but I'll have a go before giving up |
| 19:32.15 | brlcad | it's not going to be trivial using g-dxf since it specifically generates 3D dxf files |
| 19:34.29 | brlcad | if it's just a hidden line drawing you're looking for, it would probably be easier to modify rtedge to output splines |
| 19:35.26 | brlcad | if it's a hidden line _image_ you're looking for, that's specifically what rtedge generates |
| 19:35.49 | pier | not really |
| 19:35.51 | brlcad | just without the ability to annotate as it's a raster image, not vector line drawing |
| 19:36.48 | brlcad | have recently discussed that it'd be fairly easy to implement an rtannotate of sorts that could add annotations to an image and render as an overlay (or be an option to rtedge even) |
| 19:38.01 | brlcad | the main problem is that the .g files are generally modeled using implicit geometric primitives |
| 19:38.16 | brlcad | dxf only supports explicit geometric primitives |
| 19:38.23 | pier | mmh I am going to have a look at the file format got from rtedge -o |
| 19:40.01 | brlcad | so you have to either 1) convert to splines, 2) convert to triangles (which is what g-dxf does), or 3) write a research paper ;) |
| 19:41.04 | pier | looks like rtedge -o produces a binary... |
| 19:41.38 | brlcad | output is .pix file format (an image) |
| 19:41.49 | brlcad | pix-png <image.pix > image.png |
| 19:42.15 | brlcad | or rtedge -F/dev/Xl to display directly to a window |
| 19:42.38 | pier | ok but it would be incredibly difficult to get lines and oder stuf from a pix file |
| 19:42.48 | brlcad | at that point it would |
| 19:42.56 | brlcad | but inside rtedge, not so difficult |
| 19:43.26 | pier | go on |
| 19:45.04 | brlcad | inside rtedge, it has the model that it's firing rays at |
| 19:45.12 | pier | you mean I could workout a new routine studying rtedge source and make it to output a vector image file? |
| 19:45.32 | brlcad | yes |
| 19:45.47 | brlcad | it could be spline curves |
| 19:45.51 | brlcad | or even something like svg |
| 19:45.55 | pier | like in the old days commodor assembler games |
| 19:46.32 | pier | projecting an image on a plane with a given normal vector |
| 19:46.46 | brlcad | for a 2D dxf, it needs the outline curve of a primitive |
| 19:47.15 | brlcad | you could also get this by performing 2D projections of the basic primitive shapes, but with CSG operations, this becomes very very non-trivial |
| 19:47.46 | pier | yep |
| 19:48.13 | pier | sorry for being slow in understanding |
| 19:48.32 | brlcad | no problem, it's a common issue mainly stemming from implicit vs. explicit |
| 19:50.04 | brlcad | iff the purpose is to get annotations/dimensions by using qcad |
| 19:50.17 | brlcad | the main issue is "getting the object outlines" |
| 19:51.02 | pier | for outlime you mean the lines that define the profile of the object? |
| 19:51.07 | pier | outline |
| 19:51.09 | brlcad | you could do this by performing a 3D projection of the triangles in g-dxf and computing inside/outside points, stitching together a spline |
| 19:51.37 | pier | yes that was what I wanted to do |
| 19:51.38 | brlcad | you could also do this in rtedge which has already formed the projection to 2D, requiring you to just stitch together a spline |
| 19:52.03 | brlcad | right, the outlines define the profile |
| 19:52.25 | brlcad | both/either approach could be made to work |
| 19:53.20 | brlcad | gut feeling is that it'd be a fair bit easier in rtedge, though g-dxf might make more sense in the long run |
| 19:54.12 | pier | say rtedge has a part in wich it makes all the "calculus" so what it is to modify is the piece of code that prepare the output |
| 19:54.48 | pier | in order to make it write a dxf file rather than a pix file |
| 19:55.02 | brlcad | right |
| 19:55.26 | pier | then I'll switch to rtedge |
| 19:55.40 | pier | and have a look at it |
| 19:55.55 | brlcad | hey, might just give g-dxf a try first |
| 19:56.15 | brlcad | that does "make more sense" as it is the exporter |
| 19:56.47 | brlcad | it's just not clear to me even exactly how to proceed |
| 19:56.48 | pier | now I am puzzled |
| 19:57.51 | brlcad | you would not be able to reimport the 2D dxf back into brl-cad when you're done without adding 2D support to dxf-g |
| 19:59.15 | brlcad | i'd say keep going the g-dxf route unless you hit a brick wall and get stuck -- if/when that happens, maybe switch to rtedge instead |
| 19:59.15 | pier | but that issue doesn't iterest me now (and what's more would reeeeallyyyy beyond me) |
| 19:59.54 | brlcad | more than happy to support you and help you understand what's going on in g-dxf and/or rtedge |
| 20:00.12 | brlcad | both are pretty much contained to a single file for their entire main implementation |
| 20:00.40 | pier | Lord! I am not a professional programmers and in that case I might turn in a thorn in your side |
| 20:00.46 | pier | programmer |
| 20:01.16 | brlcad | what we're working on is a means to add the annotations directly in brl-cad |
| 20:01.37 | brlcad | first as a raster-only means via something that would be named like rtannotate |
| 20:01.55 | brlcad | later as a fundamental capability where you can specify annotations and dimensions in the modeler |
| 20:02.22 | archivist | swap later and first please |
| 20:03.08 | pier | sounds scary |
| 20:03.18 | brlcad | the first can be done in just a couple days |
| 20:03.24 | pier | :) |
| 20:03.50 | brlcad | the latter is a deep change and requires adding a new primitive type, modifying the .g format, and adding modeler interface improvements |
| 20:04.39 | pier | I can't see how to make such thing (the first ex later) |
| 20:05.04 | pier | perhaps |
| 20:05.58 | brlcad | i.e. the latter is brl-cad 8.x material, it breaks compatibility to support it fully |
| 20:05.59 | pier | adding a new method to the shape |
| 20:06.34 | brlcad | that's a possibility |
| 20:06.39 | brlcad | hmm |
| 20:07.00 | brlcad | that's not a bad idea |
| 20:07.37 | brlcad | could add explicit outline projection routines where you query a primitive from a particular direction and it performs the 2D projection to a given plane |
| 20:07.39 | pier | a new primitive that could inherit all the legacy from the old ones |
| 20:07.52 | brlcad | that could be done without breaking anything |
| 20:08.18 | pier | and dimensions to |
| 20:08.21 | pier | too |
| 20:08.48 | pier | with hidden and visibility flag |
| 20:08.54 | brlcad | the actual dimensions and annotations themselves are still not so trivial |
| 20:09.03 | brlcad | they do require a new primitive |
| 20:09.40 | brlcad | what I was talking about is something better than performing projections in g-dxf or trying to extract non-raster connectivity in rtedge |
| 20:10.03 | brlcad | have to think about it some more |
| 20:10.33 | brlcad | csg operations might make it impossible still |
| 20:10.41 | pier | a primitive has its dimensions |
| 20:10.58 | pier | radious for sph, vertex etc |
| 20:11.32 | brlcad | sure, a sphere is fairly trivial |
| 20:11.59 | brlcad | harder ones would be something like extracting an outline of a dsp (terrain) or even a torus rotated on an angle |
| 20:12.39 | pier | once they are known one need a method to draw the dimension on the chosen plane |
| 20:13.17 | brlcad | that was part of the idea of rtannotate |
| 20:17.33 | pier | in the case of a torus you would need a plan view of it in any case if one want to put dimensions on it |
| 20:20.23 | pier | funny... I can't see the pix image got with the rtedge fresa.g -o fresa.pix |
| 20:22.14 | brlcad | pix is a first quadrant raw image format (old sgi standard) |
| 20:22.27 | brlcad | you can read them with photoshop, or just use the brl-cad image tools |
| 20:22.40 | brlcad | pix-fb -F/dev/Xl fresa.pix |
| 20:23.09 | brlcad | plus your rtedge doesn't look right: rtedge -o fresa.pix fresa.g some_object |
| 20:24.06 | pier | It is visible with pix-fb -F/dev/Xl fresa.pix |
| 20:24.15 | pier | not with gimp |
| 20:50.57 | brlcad | you have to rename it for gimp |
| 20:51.09 | brlcad | rename it to .raw and gimp should be happy |
| 20:51.16 | brlcad | it thinks .pix are something else |
| 20:51.22 | pier | I'll try |
| 20:52.01 | brlcad | it will be flipped, if you open in gimp/photoshop as it is stored as a 1st quadrant image, they assume 4th quadrant |
| 20:52.31 | pier | get an error |
| 20:53.07 | brlcad | what error? |
| 20:53.18 | pier | unknown file type |
| 20:53.19 | brlcad | there's no magic to it .. it's just a plain raw image :) |
| 20:53.40 | brlcad | ah, I think you have to tell gimp that it's raw |
| 20:53.58 | brlcad | there's a drop-down iirc |
| 20:54.03 | pier | as a matter of fact I fancied that renaming would have been useless |
| 20:54.21 | brlcad | photoshop insists it be named .raw |
| 20:55.18 | pier | xv doesn't recognise it as well |
| 20:55.31 | pier | neither image magic |
| 20:55.38 | brlcad | heh, they will/can |
| 20:55.44 | pier | weird |
| 20:55.52 | brlcad | but you really have to go throught their means to specify it as raw |
| 20:55.55 | pier | is my pc haunted? |
| 20:55.56 | brlcad | which is not a common format |
| 20:56.06 | brlcad | so it's usually a special option/selection |
| 20:56.18 | brlcad | regardless.. if you want to see it, convert it to a different format |
| 20:56.19 | pier | I'll open the gimp again |
| 20:56.23 | brlcad | pix-[tab][tab] |
| 20:56.48 | brlcad | pix-png being the most generally useful |
| 20:57.23 | brlcad | pix-ppm useful for coding, latter versions of xv and gimp read it |
| 21:08.49 | pier | ....... have to kill mged |
| 21:09.04 | pier | it gets stuck after giving |
| 21:09.27 | pier | rtedge -o fresa.pix fresa.g telaio.r |
| 21:10.45 | pier | but not after |
| 21:10.48 | pier | rtedge -o fresa.pix fresa.g |
| 21:11.27 | pier | and |
| 21:11.32 | pier | pix-png fresa.pix |
| 21:11.59 | pier | gives a ot of rubbish on the screen and no png file |
| 21:17.25 | ``Erik | pix-png fresa.pix > fresa.png |
| 21:18.03 | ``Erik | rtfm o.O :) |
| 21:19.28 | pier | ok |
| 21:20.58 | pier | nice one! |
| 21:21.31 | pier | even though the fresa (router) came with a foot cut into two parts |
| 21:27.12 | brlcad | oh, rtedge inside of mged is different than outside, I gave syntax for outside mged |
| 21:27.24 | brlcad | inside mged, you don't need to specify the geometry or the .g |
| 21:27.30 | brlcad | it uses what's currently displayed |
| 21:29.53 | brlcad | that "rubbish" is the png file data ;) so you have to redirect it |
| 21:30.23 | brlcad | the command should have a check added to make sure output isn't a terminal like the other converters do, someone must have missed it |
| 21:31.23 | pier | ok it works |
| 21:31.44 | CIA-6 | BRL-CAD: 03brlcad * 10brlcad/TODO: pix-png should make sure output is not to a terminal |
| 21:32.39 | pier | but does not accept -w -n parameter |
| 21:32.48 | brlcad | what doesn't? |
| 21:33.24 | pier | ~/brlcad/bin$ pix-png -w 1024 -n 768 fresa.pix > fresa.png |
| 21:33.25 | pier | pix-png: Short read |
| 21:33.41 | brlcad | short read, fresa.pix isn't 1024x768 apparently |
| 21:33.53 | brlcad | default is 512x512 |
| 21:34.00 | pier | ok |
| 21:34.03 | brlcad | you have to specify 1024x768 when you render |
| 21:34.18 | pier | ok ok |
| 21:35.00 | brlcad | rtedge -w 1024 -n 768 -V1024,768 -o ... |
| 21:36.47 | pier | gas |
| 21:36.52 | pier | ok |
| 21:37.47 | brlcad | ? |
| 21:38.02 | pier | as I am going to bed would you kindly address me to the source of rtedge to ease my sleep :) |
| 21:38.13 | pier | I got lost in |
| 21:38.46 | pier | brlcad-7.6.6.src.tar.gz/brlcad-7.6.6/src/rt |
| 21:39.43 | pier | rtedge -w 1024 -n 768 -V1024,768 -o ... Was perfect |
| 21:42.00 | brlcad | if you were still here, I would have said viewedge.c |
| 21:42.03 | *** join/#brlcad pier (n=pier@151.56.213.59) |
| 21:42.06 | brlcad | heh |
| 21:42.13 | brlcad | viewedge.c |
| 21:43.03 | brlcad | all the raytracers basically just provide implementation for a set of callbacks |
| 21:43.30 | brlcad | view.c is rt's, viewedge.c is rtedge's, vieweight.c is rtweights's etc etc |
| 21:43.56 | pier | ok .. found |
| 21:44.11 | brlcad | main.c and opt.c and most of the rest of files are common to all of them |
| 21:44.35 | brlcad | rtsimple.c and rtexample.c give a tutorial on how they all work |
| 21:44.47 | brlcad | with a relatively simple raytracer that just fires one ray |
| 21:59.58 | pier | going to have a printout of rtexample.c and study it. May I be back with questions? Hope not though! |
| 22:02.53 | brlcad | sure sure |
| 22:03.05 | brlcad | it should compile outright, it's part of the build actually |
| 22:03.23 | brlcad | viewedge.c is just the callbacks that are in rtexample.c |
| 22:03.42 | brlcad | rtexample is a full program example |
| 22:04.01 | pier | yes I see |
| 22:04.47 | pier | Would gcc compile it? |
| 22:04.50 | brlcad | sure |
| 22:05.16 | pier | ....... an example perhaps... |
| 22:05.54 | brlcad | [morrison@hole (Thu Dec 22 17:05:29) ~/brlcad/src/rt]$ gcc -L/usr/brlcad/lib -I/usr/brlcad/include -I/usr/brlcad/include/brlcad rtexample.c -o rtexample -lbu -lrt |
| 22:05.56 | brlcad | [morrison@hole (Thu Dec 22 17:05:42) ~/brlcad/src/rt]$ ./rtexample |
| 22:05.59 | brlcad | Usage: rtexample model.g objects... |
| 22:07.44 | pier | Thanks a lot to you all. A merry Christmas. Good night! |
| 22:08.15 | brlcad | same to you |
| 22:09.53 | *** part/#brlcad pier (n=pier@151.56.213.59) |
| 22:12.35 | *** join/#brlcad PrezKennedy (n=Apathy@pcp0011645240pcs.aberdn01.md.comcast.net) |