Lunch Time Tracer 0.1

[lutter]

Ja, einfach forken und mir mitteilen, dass ich das übernehmen soll (ob das ein Pull-Request auf GitHub ist oder ein Post im Forum ist egal).

[rapso]

Wäre schön, wenn wir uns auf ein Dateiformat einigen könnten und dann einige schöne Szenen bereitstellen könnten. Ich habe mich mal an POV-Ray orientiert, aber einige Vereinfachungen gemacht, damit der Parser nicht zu kompliziert wurde.

da formate nicht teil des eigentlichen tracers sind, werden sie, wie angedeutet, als "plugins" gebunden sein.
ich denke mit der zeit werden wir mehr und mehr formate nutzen koennen. es gibt kein tolles alles koennendes format, gerade fuer tracer. es kann sein dass du super high poly geometry haben moechtest, es kann sein dass du procedurale dinge moechtest, es kann sein dass du die scene scripten moechtest etc.

sich auf eines einigen waere also eigentlich "alle anderen ausschliessen".

Ausserdem bräuchten wir ein besseres Image-Backend als P3, die Dateien werden so riesig.

P3? meinst du dateiformate die rausgeschrieben werden?

Lizenz: Wäre GPL oder BSD-Lizenz ok? Bei lizenzloser Software weiss man nie, was machen.

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.

rapso schrieb:

asfdlol schrieb:

Und gibt's Präferenzen was die Hochlade-Webseite angeht? Github und dergleichen sind ja für Open-Source relativ populär, müsste ich mir dann bei Bedarf noch erstellen. Hier direkt ins Forum rein wird mit der Zeit garantiert unübersichtlich (war bestimmt auch nicht gewollt).

ich werde den source drop via download als .zip anbieten (dropbox oder so). ich moechte den code soweit modular halten, dass es praktisch kein sharing gibt zwischen den leuten (wenn du auf etwas von jemandem anderen aufbauen willst, dann darfst du von seiner sache ableiten, oder ihr tut euch zusammen und submitted eine version) und somit ein CVS nicht wirklich noetig ist. aber natuerlich steht es den leuten frei es bei github, sourceforge etc. unter der bestehenden license einzuchecken.

features und bugfixes von euch bitte per mail (in einer zip) und ich integriere das per hand.

Ist dieser Workflow nicht viel zu kompliziert? Jeder macht ein Repo und forkt das, was er will. Du machst halt das Master-Repo mit der gewünschten Dateistruktur.

mir passt der workflow gut, da ich mit dem erhalten des 'commits' von den leuten die 'schenkung' als license habe. (ich denke nicht, dass wir hier bahnbrechende dinge oder entscheident viel arbeit machen um etwas total wertvolles zu generieren, aber wenn jemand angst hat mir was zu 'schenken' damit jeder es sieht macht das nichts. der code wird so modular sein, dass man sich eine neue version ziehen kann ohne seine eigenen sourcen zu beeintraechtigen (esseiden es gibt mal ein interface change).

lutter schrieb:

Hier mein Beitrag: https://github.com/cxxlutter/lutter

ein bisschen fancier als ich es geschrieben haette, aber die vector class scheint zu machen was sie sollte und ist im namespace

ein paar verbesserungswuensche damit ich das als die referenz implementierung setze haette ich. interna lasse ich unzensiert, da hat jeder seinen style, aber ein paar externe dinge:
wichtig:
-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?)
-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.
-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.

mediocre:
-koenntest du noch eine "length" funktion als member verbauen? das ist eigentlich gaengig (koenntest du ja auch direkt beim normalize nutzen).
-"norm_squared" koennte "LengthSquared" sein (style ist dir ueberlassen), ist an sich auch gaengig
-"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).
-"component_wise_multiplication" das ist doch nur ein operator*(vector lhs, vector const& rhs); oder uebersehe ich da etwas? ich denke das waere vollkommen legitim und dasselbe component wise division. die funktionen werden ja nicht nur fuer vector algebra benutzt, ich werde die vector4d gleich als color_t typedeffen falls du nichts dagegen hast. dort ist division gaengig.

minor:
-"squared" ist nicht wirklich noetig. das kann man mit den operatoren ja schon super machen, sonst waere sowas wie 'halved' auch noetig.
-min/max/abs waere nuetzlich
-clamp waere auch nett
-lerp waere nett
-dein *-1 mul beim operator- ist erstmal ok, aber besser waere wenn du die elemente invertieren wuerdest. ich denke ein *-1 wird weniger potential zum optimieren bieten bei dingen wie -a+b.

danke soweit, freue mich dass es nicht damit endet dass ich der einzige contributor bin

[rapso]

noch ein freiwilliger fuer ein wenig logging

zZ ist es nicht viel mehr als

#define LTT_LOG_LEVEL(X)
#define LTT_LOG_BREAK(X)
#define LTT_LOG_INFO printf
#define LTT_LOG_WARNING printf
#define LTT_LOG_ERROR printf
#define LTT_LOG_CRITICAL printf
#define LTT_LOG_DEBUG printf

log level sollte erlauben dass man setzt was gelogt bzw ignoriert wird.
log break sollte anhalten wenn etwas von diesem typ passiert

[Fytch]

Hier mal bisschen was von mir: https://github.com/TrippyColors/Lunch-Time-Tracer
Der versprochene Bitmap-Exporter ist mit dabei. Ich habe das Ganze aber mal C++03-Kompatibel gehalten, daher auch bisschen was von TypeTraits.hpp reinkopiert. Anregungen erwünscht.

Edit:
Pull request an lutter ist raus.

[Fytch]

rapso schrieb:

noch ein freiwilliger fuer ein wenig logging

Ich habe sowas (Logging) noch nie gemacht und weiss nun nicht, ob ich dich richtig verstanden habe, aber hier mal mein Ansatz (jedoch keine Funktionsmakros und kein printf ):

// Log.hpp

#include <cstdlib>
#include <iostream>

namespace LTT
{
	class IgnoreStreamT
	{
		IgnoreStreamT(IgnoreStreamT const& Rhs);
		IgnoreStreamT& operator= (IgnoreStreamT const& Rhs);

	public:
		IgnoreStreamT()
		{
		}
	};

	IgnoreStreamT IgnoreStream;

	template<typename T>
	IgnoreStreamT& operator<< (IgnoreStreamT& Stream, T const& Object)
	{
		return Stream;
	};

	class AbortStreamT
	{
		AbortStreamT(AbortStreamT const& Rhs);
		AbortStreamT& operator= (AbortStreamT const& Rhs);

	public:
		AbortStreamT()
		{
		}
	};

	AbortStreamT AbortStream;

	template<typename T>
	AbortStreamT& operator<< (AbortStreamT& Stream, T const& Object)
	{
		std::abort();
		return Stream;
	};
}

#define LTT_LOG_DEBUG_LEVEL 1
#define LTT_LOG_INFO_LEVEL 2
#define LTT_LOG_WARNING_LEVEL 3
#define LTT_LOG_ERROR_LEVEL 4
#define LTT_LOG_CRITICAL_LEVEL 5

#ifndef LTT_LOG_LEVEL
#define LTT_LOG_LEVEL LTT_LOG_INFO_LEVEL
#endif // LTT_LOG_LEVEL

#ifndef LTT_LOG_BREAK
#define LTT_LOG_BREAK LTT_LOG_CRITICAL_LEVEL
#endif // LTT_LOG_BREAK

#if LTT_LOG_DEBUG_LEVEL >= LTT_LOG_BREAK
#define LTT_LOG_DEBUG (LTT::AbortStream)
#elif LTT_LOG_DEBUG_LEVEL >= LTT_LOG_LEVEL
#define LTT_LOG_DEBUG (std::clog)
#else
#define LTT_LOG_DEBUG (LTT::IgnoreStream)
#endif

#if LTT_LOG_INFO_LEVEL >= LTT_LOG_BREAK
#define LTT_LOG_INFO (LTT::AbortStream)
#elif LTT_LOG_INFO_LEVEL >= LTT_LOG_LEVEL
#define LTT_LOG_INFO (std::clog)
#else
#define LTT_LOG_INFO (LTT::IgnoreStream)
#endif

#if LTT_LOG_WARNING_LEVEL >= LTT_LOG_BREAK
#define LTT_LOG_WARNING (LTT::AbortStream)
#elif LTT_LOG_WARNING_LEVEL >= LTT_LOG_LEVEL
#define LTT_LOG_WARNING (std::clog)
#else
#define LTT_LOG_WARNING (LTT::IgnoreStream)
#endif

#if LTT_LOG_ERROR_LEVEL >= LTT_LOG_BREAK
#define LTT_LOG_ERROR (LTT::AbortStream)
#elif LTT_LOG_ERROR_LEVEL >= LTT_LOG_LEVEL
#define LTT_LOG_ERROR (std::clog)
#else
#define LTT_LOG_ERROR (LTT::IgnoreStream)
#endif

#if LTT_LOG_CRITICAL_LEVEL >= LTT_LOG_BREAK
#define LTT_LOG_CRITICAL (LTT::AbortStream)
#elif LTT_LOG_CRITICAL_LEVEL >= LTT_LOG_LEVEL
#define LTT_LOG_CRITICAL (std::clog)
#else
#define LTT_LOG_CRITICAL (LTT::IgnoreStream)
#endif

// main.cpp

#define LTT_LOG_LEVEL LTT_LOG_DEBUG_LEVEL
#define LTT_LOG_BREAK LTT_LOG_ERROR_LEVEL

#include <LTT/Log.hpp>

int main()
{
	std::clog.rdbuf(std::cout.rdbuf());

	LTT_LOG_DEBUG << "Hello Debug!\n";
	LTT_LOG_INFO << "Hello Info!\n";
	LTT_LOG_WARNING << "Hello Warning!\n";
	LTT_LOG_ERROR << "Hello Error!\n";
	// LTT_LOG_CRITICAL << "Hello Critical!\n";
}

http://ideone.com/tjJVxv

Kann auf Rückmeldung hin Dinge abändern und, wenn's dann passt, auf GitHub meinem Repository hinzufügen.

[rapso]

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

[Fytch]

So, habe es nun neu geschrieben. Es wäre nun auch auf GitHub (da gäbe es auch einen Download Button).

[raps]

danke, ist angekommen, perfektes timming vor dem lunch

[lutter]

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!

[VitC]

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?

[rapso]

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

[rapso]

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.)

[Fytch]

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]

typedef reicht dank ADL doch, oder sehe ich das falsch?

[rapso]

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]

typedef reicht 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.

[lutter]

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?

[rapso]

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.

[rapso]

@lutter
danke, ist angekommen, werde ich morgen in der mittagspause verbauen

[rapso]

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).