Lunch Time Tracer 0.1
-
schaut gut aus
die levels koennten eine bitmask sein ueber die man festlegt was man sehen moechte, z.b. koennte man 'debug' sehen wollen ohne die warnings zu sehen weil man damit arbeitet. oder warnings ohne debug, weil der user nicht mit dem eigenen debug zeug gespamt werden sollte.
das sollte ein laufzeit flag sein, weil wir das per config umstellen koennen sollten (z.b. wenn mal etwas nicht funzt, einfach die verbosity aufdrehen und vielleicht steht da schon was falsch ist).
als namespace nutze etwas was nicht LTT ist
die idee ist ja dass jeder jedes module vom tracer durch ein eigenes ersetzen koennen sollte, im fall vom logger waere es dann z.b. LTT_LOG_DEBUG auf sein modul umdefinieren.aber sonst
mail mir das
-
So, habe es nun neu geschrieben. Es wäre nun auch auf GitHub (da gäbe es auch einen Download Button).
-
danke, ist angekommen, perfektes timming vor dem lunch
-
rapso schrieb:
nein, ich moechte keines von beiden. bei z.B. POV gab es wohl viele contributors die unter einer lizens beitrugen die es denen jetzt nicht mehr erlaubt auf GPL oder sowas zu wechseln und auch aenderungen sind wohl lizensmaessig aufwendig. wenn ich ein wenig GPL, ein wenig BSD, ein wenig LGPL code bekomme... ich kann rechtlich nicht sagen wie sich was mit was vertraegt und kann niemandem abnicken dass das was er damit machen will fuer alle auch ok waere.
deswegen meine stumpfe 'lizens' dass der code fuers lernen bzw akademisch genutzt werden kann.Wenn ich dir mein Code "schenke" bzw. Erlaubnis gebe, damit zu machen, was du willst, solltest du doch keine Probleme haben, oder?
rapso schrieb:
-kannst du cross etc. als member verbauen? statt z.b. dem typedef auf vector3d und dann ein cross was intern prueft ob es ein vector3 ist, eine spezialisierte klasse wo cross ein member ist. dasselbe fuer normalized etc. (wobei die in die base class koennten?)
Könnte ich machen, aber ich bin der Meinung, dass cross (genau wie dot) keine Memberfunktion sein sollte, da die beiden Operanden gleichberechtigt sind und es keinen Grund gibt, das nicht als freie Funktion zu schreiben.
rapso schrieb:
-koennten die restlichen assert static_asserts werden? soweit ich sehe sollte alles compile time evaluiert werden koennen. das waere schneller im debug und man haette bugs zur compile time abgedeckt bevor man jeden case wirklich testen muss.
Habe den Dimensions-Check nun auf Compile-Time verschoben.
-kannst du bitte implementierung in ein .inl stecken damit die deklarationen einfach sichtbar sind please? dein code ist an sicht gut lesbar, aber ich wuerde es gerne standard maessig so halten, damit ich nicht debatieren muss ab wann es unuebersichtlich waere.
Ist ein Auslagern der Implementierung in bits/<file>.hpp in Ordnung? Sonst benenne ich das in bits/<file>.inl um.
rapso schrieb:
-koenntest du noch eine "length" funktion als member verbauen? das ist eigentlich gaengig (koenntest du ja auch direkt beim normalize nutzen).
Gibts zwar schon als freie Funktion (std::abs), aber ich habe normalize() und length() mal zu vector und quaternion hinzugefügt.
-"norm_squared" koennte "LengthSquared" sein (style ist dir ueberlassen), ist an sich auch gaengig
Habs in length_squared umbenannt.
-"normalized" waere dann auch ein vector accessor, wenn du es zusaetzlich als 'friend' haben moechtest, finde ich auch ok, sollte dann vielleicht den anderen funktionen entsprechend 'normalize' heissen. (die heissen ja auch dot und nicht dotted und cross und nicht crossed).
normalized -> gibt einen neuen Vektor zurück. normalize -> normalisiert den übergebenen Vektor.
-"component_wise_multiplication" das ist doch nur ein operator*(vector lhs, vector const& rhs); oder uebersehe ich da etwas?
Geändert. Dachte, das führt zur Verwirrung, weil quaternion die Multiplikation anders definiert, ist aber denke ich ok.
-"squared" ist nicht wirklich noetig. das kann man mit den operatoren ja schon super machen, sonst waere sowas wie 'halved' auch noetig.
squared reduziert Redundanz: (ausdruck*4-6)*(ausdruck*4-6) wird zu squared(ausdruck*4-6) und ist mMn übersichtlicher. Muss man ja nicht benutzen.
-min/max/abs waere nuetzlich
Für vector? abs gibt es schon, und der gibt die Länge zurück. Meinst du einen komponentenweisen Vergleichsoperator oder das minimale/maximale Element des vectors? Es gibt dazu ja auch
(std::max_element(v.begin(), v.end());-clamp waere auch nett
Gab es schon, ist nun aber in utils.hpp verschoben.
-lerp waere nett
Habs mal hinzugefügt, auch wenn ich es nicht brauche.
-dein *-1 mul beim operator- ist erstmal ok, aber besser waere wenn du die elemente invertieren wuerdest.
ok.
Danke fürs drüberschauen!
-
Sehr interessantes Projekt, auch wenn ich C und nicht C++-Programmierer bin. Aber ich will auch neben einer reinen Software-3D-Engine auch eine Raytracer schreiben. Allerdings bin ich auch noch bei diesem ganzen Bloatzeugs(Kannte den Begriff vorher gar nicht). Wie dem auch sei, ich werde sicherlich mal hier öfters in den Thread rein schauen, da das Thema an sich auch #Neuland für mich ist.
Wollt ihr eigentlich auch ein paar theoretische Grundlagen hier posten, vielleicht auch später Optimierungen durch Bäume oder so?
-
VitC schrieb:
Sehr interessantes Projekt, auch wenn ich C und nicht C++-Programmierer bin. Aber ich will auch neben einer reinen Software-3D-Engine auch eine Raytracer schreiben. Allerdings bin ich auch noch bei diesem ganzen Bloatzeugs(Kannte den Begriff vorher gar nicht).
bloat versuche ich zu vermeiden, ausser dem c++ standard wird nichts fest verbaut.
wobei es den leuten natuerlich frei steht ihre module mit bevorzugten libs zu erweitern.Wollt ihr eigentlich auch ein paar theoretische Grundlagen hier posten, vielleicht auch später Optimierungen durch Bäume oder so?
wenn jemand etwas neues verbaut waere es sehr nett einen report zu bekommen. viel mehr sinn als dinge zu lernen hat die sache nicht (naja, und: spass). waere also nett zu hoeren was die leute vorhaben, das gilt nicht nur fuer optimierungen. zZ koennen folgende dinge schon beliebig ausgetauscht werden:
- math (vector3 zZ, wird spaeter erweitert)
- SceneLoader (z.b. obj loader/paser, die koennen sich rekursiv aufrufen)
- ImageLoader (fuer z.b. texturen)
- ImageSaver (um das finale bild zu speichern)
- Generator (randomizer, poisson sampling, was fuer antialiasing, integrieren von brdfs, samplen von texturen, volume marching,... benutzt werden kann)
- Node (vom scene graph)
- Primitive (z.B. planes, sphere, patches, volumes, voxel, ...)
- Light (...)
- Camera (pinhole, 360grad, texture renderer,...)
- Accelerator (zum tracen, z.b. octree)
- Logger (...)
es fehlt mir noch eine geniale idee wie ich verschiedene tracer arten mit verschiedenen material arten kombinieren kann. z.b. wird ein witthed tracer selbst anhand der materialien entscheiden wie weiter vorgegangen wird (z.b. 128 rays zur lichtquelle schicken um soft shadows zu haben), ein uni directional path tracer hingegen wird eher vom material bestimmen lassen wie rays verschossen werden (mirror, transparent, ... haben unterschiedliche ansprueche) dafuer gibt es aber immer nur 1 oder 0 rays.
es gibt grundsaetzlich "passes" sodas eine art von tracer andere involvieren kann z.b. ein photon scatter pass um dann photon gathering zu betreiben.
also das kommt noch dazu
- passes
- brdf/material
- output merger (das was entscheided wie die samples zu pixeln werden)
- animatoren (aka modifier aka... z.B. um nodes zu roetieren, damit man sowas wie 'motion blur' samplen koennte)
- ...
die 3 ersten sind eigentlich was fehlt bis zur release.
ich nehme die sache fuer version 1 vielleicht mitnachhause uebers WE damit es einen schub gibt, 1h coden ist echt nicht viel beim lunch
-
lutter schrieb:
Wenn ich dir mein Code "schenke" bzw. Erlaubnis gebe, damit zu machen, was du willst, solltest du doch keine Probleme haben, oder?
jup, das war nur die erklaerung weshalb ich keine bestehende nehme.
rapso schrieb:
-kannst du cross etc. als member verbauen? statt z.b. dem typedef auf vector3d und dann ein cross was intern prueft ob es ein vector3 ist, eine spezialisierte klasse wo cross ein member ist. dasselbe fuer normalized etc. (wobei die in die base class koennten?)
Könnte ich machen, aber ich bin der Meinung, dass cross (genau wie dot) keine Memberfunktion sein sollte, da die beiden Operanden gleichberechtigt sind und es keinen Grund gibt, das nicht als freie Funktion zu schreiben.
das sehe ich auch so, aber ich wuerde gerne die lib durch ein einfaches typedef freigeben (und den namespace nicht global oeffnen). deswegen die nicht ganz so schoene loesung dass man dann a.dot(b) schreibt.
bin fuer bessere loesungen offen. [edit]rewiediere, das unten finde ich sauberer[/edit]-kannst du bitte implementierung in ein .inl stecken damit die deklarationen einfach sichtbar sind please? dein code ist an sicht gut lesbar, aber ich wuerde es gerne standard maessig so halten, damit ich nicht debatieren muss ab wann es unuebersichtlich waere.
Ist ein Auslagern der Implementierung in bits/<file>.hpp in Ordnung? Sonst benenne ich das in bits/<file>.inl um.
.inl waere nett.
der stumpfe gedanke dabei ist, dass sich leute eventuel sogar die *.hpp kopieren und ihre eigenen .inl basteln, z.b. zum grundlagen ueben (e.g. operator overloading). oder ein paar 'optimierungen' z.b. den carmack trick statt einem echten normalize mit sqrt. etc.rapso schrieb:
-koenntest du noch eine "length" funktion als member verbauen? das ist eigentlich gaengig (koenntest du ja auch direkt beim normalize nutzen).
Gibts zwar schon als freie Funktion (std::abs), aber ich habe normalize() und length() mal zu vector und quaternion hinzugefügt.
selber beweggrund wie oben, dass mit einem typedef lutter::vector3d vec3_t; alles verfuegbar wird.[edit]rewiediere...
-"component_wise_multiplication" das ist doch nur ein operator*(vector lhs, vector const& rhs); oder uebersehe ich da etwas?
Geändert. Dachte, das führt zur Verwirrung, weil quaternion die Multiplikation anders definiert, ist aber denke ich ok.
das waere dann aber der quartenion type der das macht. matrix wird ja auch eine mathe-konforme implementierung haben (auch wenn man manchmal auch komponentwise machen wuerde).
ich typedef deinen vector4d auch direkt auf color_t; da kommt es einem dann ganz natuerlich vor dass es komponentwise ist.-"squared" ist nicht wirklich noetig. das kann man mit den operatoren ja schon super machen, sonst waere sowas wie 'halved' auch noetig.
squared reduziert Redundanz: (ausdruck*4-6)*(ausdruck*4-6) wird zu squared(ausdruck*4-6) und ist mMn übersichtlicher. Muss man ja nicht benutzen.
da waren meine bedenken, dass wenn du es einbaust und es verwendet wird, es ein sehr spezieller case ist den jeder der nachfolgend den vector imlementieren moechte, auch nachbauen muss.[edit]rewiediere...
-min/max/abs waere nuetzlich
Für vector? abs gibt es schon, und der gibt die Länge zurück. Meinst du einen komponentenweisen Vergleichsoperator oder das minimale/maximale Element des vectors? Es gibt dazu ja auch
(std::max_element(v.begin(), v.end());-clamp waere auch nett
Gab es schon, ist nun aber in utils.hpp verschoben.
-lerp waere nett
Habs mal hinzugefügt, auch wenn ich es nicht brauche.
eigentlich hast du recht, es klingt sinniger das extern in eine mathutility lib zu stecken. solange das interface der vector lib gut definiert ist, sollte jede vector lib damit funzen und auf der anderen seite koennten leute die helper lib ersetzen ohne dass die vector klasse angefasst werden muss. (und es passt mehr zu sowas wie glsl/hlsl/cg wo die vector primitiven nur operator ueberladungen haben und alles andere als utility geliefert wird.)
wenn du also so nett waerst cross, dot, normalize (nicht den normalized() accessor, aber der koennte normalize aufrufen) etc. in deine utility-lib zu stecken. dann verbaue ich die.
(waere nett wenn die beiden nicht 'zu' abhaengig sind, damit sie austauschbar bleiben. damit meine ich nichts spezifisches, nur als hint.)
-
rapso schrieb:
zZ koennen folgende dinge schon beliebig ausgetauscht werden:
Mit "können ausgetauscht werden" ist gemeint, dass diese schon implementiert worden sind?
rapso schrieb:
das sehe ich auch so, aber ich wuerde gerne die lib durch ein einfaches typedef freigeben (und den namespace nicht global oeffnen). deswegen die nicht ganz so schoene loesung dass man dann a.dot(b) schreibt.
bin fuer bessere loesungen offen. [edit]rewiediere, das unten finde ich sauberer[/edit]typedefreicht dank ADL doch, oder sehe ich das falsch?
-
asfdlol schrieb:
rapso schrieb:
zZ koennen folgende dinge schon beliebig ausgetauscht werden:
Mit "können ausgetauscht werden" ist gemeint, dass diese schon implementiert worden sind?
es gibt ein interface und je mindestens eine implementierung.
- math (zZ mein dummy damit es baut, aber dann lutters)
- SceneLoader (orginal cornell box)
- ImageLoader (tga, wird aber noch nirgens verwendet)
- ImageSaver (hdr bzw rgbe, damit kann man das tonemapping extern erledigen)
- Generator (regular grid)
- Node (nur die hierarchy, noch keine transforms oder sonst was)
- Primitive (rect, das ist was die cornell box verwendet)
- Light (omni light, also simpelste punkt lichtquelle)
- Camera (pinhole)
- Accelerator (lineare liste aka vector)
- Logger (hab deinen auf das interface umgestrickt, aber nur halbgar bisher,ich versuche die zeit zu finden das besser zu machen oder wir aendern das interface noch wenn du unzufrieden bist wenn ich den ersten ReleaseCandidate zum download anbiete)
rapso schrieb:
das sehe ich auch so, aber ich wuerde gerne die lib durch ein einfaches typedef freigeben (und den namespace nicht global oeffnen). deswegen die nicht ganz so schoene loesung dass man dann a.dot(b) schreibt.
bin fuer bessere loesungen offen. [edit]rewiediere, das unten finde ich sauberer[/edit]typedefreicht dank ADL doch, oder sehe ich das falsch?hast recht, hab ich so nie verwendet und vergessen wie impliziet das laeuft. aber lutters utility lib ist eh eine bessere idee.
-
Also gehe ich davon aus, dass jetzt alles in Ordnung ist? Das schöne an den allgemeinen dot/length Funktionen ist, dass sie z.B. auch für std::vector funktionieren, oder jede andere vector-Implementierung, die begin()/end()/size() und value_type anbietet.
Color gibt es übrigens schon als typedef in config.hpp.
rapso schrieb:
lutter schrieb:
Wenn ich dir mein Code "schenke" bzw. Erlaubnis gebe, damit zu machen, was du willst, solltest du doch keine Probleme haben, oder?
jup, das war nur die erklaerung weshalb ich keine bestehende nehme.
Also darf ich meinen Code in GitHub unter die GPL stellen, dir aber schenken?
-
bin uebers WE doch zu nichts gekommen, privatleben
lutter schrieb:
Also gehe ich davon aus, dass jetzt alles in Ordnung ist? Das schöne an den allgemeinen dot/length Funktionen ist, dass sie z.B. auch für std::vector funktionieren, oder jede andere vector-Implementierung, die begin()/end()/size() und value_type anbietet.
nett schon, aber an sich nicht wirklich notwendig fuer den tracer.
Color gibt es übrigens schon als typedef in config.hpp.
ja, sowas bau ich in den LTT auch ein
rapso schrieb:
lutter schrieb:
Wenn ich dir mein Code "schenke" bzw. Erlaubnis gebe, damit zu machen, was du willst, solltest du doch keine Probleme haben, oder?
jup, das war nur die erklaerung weshalb ich keine bestehende nehme.
Also darf ich meinen Code in GitHub unter die GPL stellen, dir aber schenken?
natuerlich, ist ja dein code.
den vector teil (sammt utility) den du mir schickst stelle ich dann unter die lern-license. Natuerlich darf jeder, unter beachtung dieser license, den source dann auch auf github/sourceforge/mercury/etc. stellen.
-
@lutter
danke, ist angekommen, werde ich morgen in der mittagspause verbauen
-
leider bekomme ich die lib nicht zum bauen, selbst VS2015 reported compiler bugs. ich werde meine eigene lib basteln damit man es erstmal bauen und laufen lassen kann, alternativ kann man deine vector lib nutzen und vielleicht moechte es jemand fuer windows fixen (oder ich finde ein wenig mittagszeit).