As with Kyle, I have some experience with MediaWiki - I've set it up a 
few times and we use it at work.  I'm rubbish at the stylesheets and 
whatnot, but authentication and whatnot should be fairly easy to get 
going.  What type of database is used on the backend to hold the user 
information?

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> As with Kyle, I have some experience with MediaWiki - I've set it up a
> few times and we use it at work.  I'm rubbish at the stylesheets and
> whatnot, but authentication and whatnot should be fairly easy to get
> going.  What type of database is used on the backend to hold the user
> information?
>
> Jim

Is this undertaking going to coincide with the SDL object/code repository
that was discussed sometime back?
Charles

Post a reply to this message

On Mon, 24 Sep 2007 19:50:34 -0400, Charles C wrote:

> Is this undertaking going to coincide with the SDL object/code
> repository that was discussed sometime back?
> Charles

Personally, I couldn't answer that, but I don't see why such a wiki 
couldn't include a collection of examples.

Jim

Post a reply to this message

why not go super-simple?

lighting {4pm, August 12, Milan, Italy, outdoors}
city{detail=fine}

camera{Canon AE-1, F2.8, 1/100th
	filters{anti-glare, polarized}
}

car{Bentley, color Red, very shiny}

woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}




nemesis wrote:
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> I mean: as it is now, POV-SDL has a C-like syntax.  I think it would be a
>> very bad idea to change the POV-SDL into a BASIC-like syntax, or a
>> Python-like syntax
> 
> hey, how about pretty much no syntax at all?
> 
> (union (plane y (pigment (checker 0 1)))
>          (sphere 0 1
>                  (texture (pigment (rgb x))
>                           (finish (phong 0.8 30)))))
> (light-source white (* 5 #(-1 1 -1)))
> (camera (z -3) 0)
> 
> well, except for Lots of Irritating Silly Parentheses, that is... :)
> 
> 
>

Post a reply to this message

Bryan Valencia wrote:

> why not go super-simple?
> 
> lighting {4pm, August 12, Milan, Italy, outdoors}
> city{detail=fine}
> 
> camera{Canon AE-1, F2.8, 1/100th
> filters{anti-glare, polarized}
> }

What if you don't have a Canon?

> 
> car{Bentley, color Red, very shiny}
> 
> woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
> 
> 

-- 
Ger

Post a reply to this message

andrel wrote:

> Can someone set something up somewhere?
> If not, I might feel forced to sift through this mess again to collect 
> all arguments and put them on a simple html page, but be aware that that 
> one will be highly biased and not changeable by others ;)

Ok, some of the discussion is summarized at:

http://members.chello.nl/a.c.linnenbank/newsdlforpov.html

Post a reply to this message

Bryan Valencia wrote:
> why not go super-simple?
> 
> lighting {4pm, August 12, Milan, Italy, outdoors}
> city{detail=fine}
> 
> camera{Canon AE-1, F2.8, 1/100th
>     filters{anti-glare, polarized}
> }
> 
> car{Bentley, color Red, very shiny}
> 
> woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
> 
> 
IOW, you want an SDL that fully supports DWIM.     :-)

      -=- Larry -=-

PS.  If you've never run across this acronym:  DWIM = "Do What I Mean"

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> http://members.chello.nl/a.c.linnenbank/newsdlforpov.html

  Here are some ideas of mine, if the new SDL is created as an enhancement
of the current SDL (instead of creating a completely separate new scripting
language):

* Even if it's based on the current SDL, it should still be byte-compilable
(and even JIT-compilable to native machine code if so needed), which means
that at least some backwards-compatibility must be broken and there's no
way around it. One example is that #macros can no longer be used in the
same ways as current ones, but instead they must work as pure functions.
For example, current macros can be used for "ugly" tricks like this:

#macro M(a, b)
  , a, b>
#end

sphere { <1 M(2, 3), 4 }

  This just doesn't fit in for byte-compiled code (at least not with very,
very ugly hacks which would only burden and slow down the VM interpreting
the bytecode).
  The vast majority of #macros out there already work as pure functions,
though, so only the "ugliest" ones would break.

* Existing data containers, namely arrays and strings (which are special
arrays of characters), should be enhanced and new data containers introduced.
For example the current array could be internally implemented as a C++ deque,
which would make it work like the current one plus you can freely resize it
(larger or smaller), append elements at the beginning and at the end, and
you can still access any element fast, and none of these operations will be
slow (eg. resizing does not require copying/moving any existing elements).
Even inserting or removing elements from the middle of the array would be
possible, although it would not be a constant-time operation.
  Strings could also be internally implemented as C++ strings. This would
also allow easy resizing and appending. Also any byte values should be
supported so that strings could also be used as raw byte arrays (for example
for reading and writing files in binary mode). More operators and functions
for accessing and manipulating strings should be added.

  Some syntactical technique should be introduced which would allow handling
and accessing other types of data containers as well, such as lists and
sets (balanced binary trees). Using the same idea as with C++ iterators for
this could be one possibility. This would allow offering the C++ data
containers at the SDL level.

* The language should be enhanced in such a way that you can create your
own (efficient) data containers. For this it may be necessary to introduce
the concept of modules (ie. classes without inheritance) or classes (with
perhaps a simple inheritance support) and references. These modules or
classes could have member variables and perhaps even member functions.
Accessing the elements could be done with the dot operator.

* Many of the existing features of the current SDL, such as the camera,
global_settings, etc, could be enhanced to behave like such modules/classes.
For example, I envision this kind of code being possible:

#if(global_settings.max_trace_level < 10)
  global_settings { max_trace_level 10 }
  // or alternatively: global_settings.max_trace_level = 10
#end

#declare CameraAngle = camera.angle;

  Perhaps even objects could behave like modules/classes like this, so
you could do something like:

#declare S = sphere { 0, 1 };
#declare R = S.radius;

  This could be especially useful for writing SDL libraries which modify
triangle meshes (eg. subdivision, smoothing...)

* There should be support for binary reading and writing of files (into
strings, which have been enhanced to support raw byte data). Maybe other
methods of reading and writing files could be introduced as well (in order
to make it easier to write file format parsers).

* If possible, introduce alternative ways of handling identifiers/variables
so that all of these lines are valid:

#declare Var = Var + 1;
Var = Var + 1;
#declare Var += 1;
Var += 1;

* The most difficult thing of all: Some kind of shader language, and deciding
if this will be a completely separate language from the SDL (in the same
way as current user-defined functions are) or if it will be the same.
Perhaps a limited set of the SDL itself could be used as a shader language
(for example a shader would be a macro/function which takes certain
parameters and only uses a subset of the whole SDL, and which has access
to certain special functions not accessible normally; the parser would check
that this is so).
  Ideally such shader function could do things like trace additional rays,
read information from objects, textures, etc.

* Likewise some way of post-processing the rendered image with the SDL should
be possible. This could also be, for example, a special macro/function which
takes certain parameters and which has access to certain functions.
  Ideally the post-processing step is not completely separate from the
rendering step. For It may be cool if the post-processing function could,
for example, trace new rays if it wants to.

-- 
                                                          - Warp

Post a reply to this message

I'm sure this has already been requested at some point, but I'd like to have the
ability to define image parameters from within the scene file.  These parameters must
currently be defined at the
command line or within an ini file.

For example:

#declare Image.width = 800;
#declare Image.height = 600;
#declare Image.antialiasing.threshold = 0.1;

Or alternatively, if the current syntax is retained, something like this:

#declare image_width = 800;
#declare image_height = 600;
#declare image_antialiasing_threshold = 0.1;

Post a reply to this message

Bryan Valencia nous apporta ses lumieres en ce 2007/09/25 14:16:
> why not go super-simple?
> 
> lighting {4pm, August 12, Milan, Italy, outdoors}
> city{detail=fine}
> 
> camera{Canon AE-1, F2.8, 1/100th
>     filters{anti-glare, polarized}
> }
> 
> car{Bentley, color Red, very shiny}
> 
> woman{sexiness 9.5, evening_wear{color Black fabric Silk} winking}
> 
> 
> 
>
Positive point: this simplify things for some peoples.
Negative point: this imply several HUGE libraries of premade shapes, textures, 
environments, models,...
Another negative point: Humongous code bloat. How about a 5+ Gb download?

-- 
Alain
-------------------------------------------------
If you're ever about to be mugged by a couple of clowns, don't hesitate - go for 
the juggler.

Post a reply to this message